Size: a a a

2018 September 30

IG

Ilya Gulya in GitFox
Eugene создал MR, глянул по истории, MR подобного размера уже бывали. Или стоит разбить на поменьше? Если да, то по какому признаку дробить?
https://gitlab.com/terrakok/gitlab-client/merge_requests/94
источник

ES

Eugene Shapovalov in GitFox
Посмотрю в ближйшее вркмя
источник

IG

Ilya Gulya in GitFox
ok
источник

ES

Eugene Shapovalov in GitFox
@ilyagulya
Я быстро глянул и у меня возникло несколько вопросов:

1) ты создал несколько абстракций. Будут ли они все использоваться с добавлением других custom node?
2) мне кажется, что кэшировать лейблы нужно на уровне Repository.
3) что будет, если добавится новый лейбл?
4) на экране со списком лейблы отрисовываются в квадрате, и тогда сейчас различаются реализации отрисовки их.

Я как буду дома, ещё раз гляну решение от noties, чтобы более детально сравнить реализации custom node.
источник

IG

Ilya Gulya in GitFox
Eugene Shapovalov
@ilyagulya
Я быстро глянул и у меня возникло несколько вопросов:

1) ты создал несколько абстракций. Будут ли они все использоваться с добавлением других custom node?
2) мне кажется, что кэшировать лейблы нужно на уровне Repository.
3) что будет, если добавится новый лейбл?
4) на экране со списком лейблы отрисовываются в квадрате, и тогда сейчас различаются реализации отрисовки их.

Я как буду дома, ещё раз гляну решение от noties, чтобы более детально сравнить реализации custom node.
1) Да, будут. Для того и создал. MarkdownDecorator для преобразования экстеншнов в наше внутреннее представление которое унифицированно парсится кастомным DelimiterProcessor-ом. ExtensionProcessor преобразует это представление в ноду. GitlabExtensionsDelimiterProcessor занимается отловом подобных тегов и передачей их обработки соответствующему ExtensionProcessor.
2) Вполне возможно, я запилил быстрый workaround, могу переместить куда нужно.
3) Ну, на данный момент кеш работает до тех пор пока не отпишется последний подписчик. Так что по идее новые лейблы спокойно подгрузятся. Но запросов конечно больше чем хотелось бы шлётся. Что-то более адекватное я не придумывал, глянул что в проекте подобный подход используется, предположил что оптимизацией сетевых запросов и кешированием заниматься будем позднее. То есть это решение сейчас просто чтобы совсем хардкор не происходил.
4)  Вот тут не понял
источник

ES

Eugene Shapovalov in GitFox
4) Открой issues в проекте и ты увидешь в ленте их, но в другом виде.
источник

ES

Eugene Shapovalov in GitFox
Тут надо будет спросить у Ильяса.
источник

IG

Ilya Gulya in GitFox
Eugene Shapovalov
4) Открой issues в проекте и ты увидешь в ленте их, но в другом виде.
А, ты о том что в списках вообще не нужно беспокоиться про парсинг лейблов?
источник

IG

Ilya Gulya in GitFox
Я увидел, там только title пихается.
источник

IG

Ilya Gulya in GitFox
Ща проверю
источник

IG

Ilya Gulya in GitFox
Да, они там не должны парситься
источник

ES

Eugene Shapovalov in GitFox
В списках там же они приходят вместе с проектом.
источник

IG

Ilya Gulya in GitFox
Ща гляну
источник

IG

Ilya Gulya in GitFox
Eugene там есть массив labels, да. Но он содержит только assigned лейблы.
источник

IG

Ilya Gulya in GitFox
Если в описании используются лейблы которые не привязаны к issue - их там не будет
источник

ES

Eugene Shapovalov in GitFox
Мне не понравилась различная отрисовка лейблов на двух экранах проекта.
источник

ES

Eugene Shapovalov in GitFox
Я более детально посмотрю mr чуть позже.
источник

IG

Ilya Gulya in GitFox
Eugene Shapovalov
Мне не понравилась различная отрисовка лейблов на двух экранах проекта.
Я не понимаю. Что значит различная отрисовка?
источник

IG

Ilya Gulya in GitFox
ок
источник

ES

Eugene Shapovalov in GitFox
Ну вот ты реализовал "chip", а на экране issues/mergerequests в списке они идут как прямоугольник.
источник