ES
Мы сейчас ещё не отрисовываем labels в Issue/MergeRequest info, а будем скоро.
Size: a a a
2018 September 30
IG
Ну вот ты реализовал "chip", а на экране issues/mergerequests в списке они идут как прямоугольник.
А, понял.
Ну, дизайн поправить не проблема.
Также, они в списке лейблов неправильно отрисовываются. Цвета не учитываются.
Ну, дизайн поправить не проблема.
Также, они в списке лейблов неправильно отрисовываются. Цвета не учитываются.
ES
Да, и это тоже надо фиксить, но не в рамках этой таски.
IG
Eugene Я там почитал, кое-где ответил.
Заниматься уже на неделе буду фиксами.
По поводу кодстайла - я использую кодстайл проекта, проблем быть не должно. Вполне вероятно что там где кодстайл разный, код не был отформатирован правильно изначально. У меня всегда перед коммитом стоит галка "Reformat code".
Заниматься уже на неделе буду фиксами.
По поводу кодстайла - я использую кодстайл проекта, проблем быть не должно. Вполне вероятно что там где кодстайл разный, код не был отформатирован правильно изначально. У меня всегда перед коммитом стоит галка "Reformat code".
ES
Там в основном по пустым строкам
ES
@ilyagulya
По идеи нужно загружать неи лейблы, майлстоуны и т.д, а markdown data
По идеи нужно загружать неи лейблы, майлстоуны и т.д, а markdown data
ES
Для определенного проекта
IG
@ilyagulya
По идеи нужно загружать неи лейблы, майлстоуны и т.д, а markdown data
По идеи нужно загружать неи лейблы, майлстоуны и т.д, а markdown data
Ты про момент с переносом загрузки лейблов внутрь MarkdownConverter?
ES
Волбще идея
ES
Это сейчас только ведь лейблы парсятся.
IG
Ну да, идея норм. Можно просто превратить мой ProjectMarkdownConverterProvider в такую штуку тогда
ES
Ну да, идея норм. Можно просто превратить мой ProjectMarkdownConverterProvider в такую штуку тогда
да
2018 October 01
IG
Eugene Привет. Я так и не понял зачем делать кастомный спан. В статье что ты дал наоборот говорят о том что прежде чем писать свой спан, нужно проверить, что мы действительно исчерпали возможности фреймворка.
>But, before writing your own implementations from scratch, check whether you can use the functionality provided in the framework spans.
>But, before writing your own implementations from scratch, check whether you can use the functionality provided in the framework spans.
ES
смотри, идея такого спана, что он покрашенный и clickable
ES
т.е это один спан
ES
тоже самое и issue_link, merge_request_link
ES
это не два разных, а один, у которого две функции. отрисовка + clickable
IG
Не, идею то я понял. Я не понял зачем это, если мы можем обойтись спанами фреймворка. Просто оптимизация?
ES
ну на один спан меньше и логически понятен он.
ES
кстати, его стоит переименовать в LabelSpan