Это, как понимаю, настройка CI. Но что за правило? Как jest говорит, что произошла деградация покрытия? Для этого же надо сравнить покрытие с предыдущим значением...
Уж больно джавовский подход написания кода, немного увеличивает вес самих алгоритмов. Чем проще, тем лучше виден сам алгоритм. Я не против ООП, это мое имхо.
Причина: запрос ушел, пошел рендер, а не наоборот. Я же не сказал, что производительность подскочит на 200%, я только хотел сказать, что в разрезе последовательности выполнения лучше начать запрос данных как можно раньше.
Автор, подскажите, пожалуйста, чем ваша статья кардинально отличается от достаточно качественной документации на официальном сайте vue? ru.vuejs.org/v2/guide/instance.html
Понятно что финт ушами, но это же еще реализовать надо, так же заботясь о синхронизации их обеих, если рассмотреть то же фиксед. Что и выльется в достаточно трудоемкую задачу. Я к этому) Ну флаг вам в руки, буду следить за вашей работой, посмотрим что выйдет. Хорошей продуктивной работы!
)))
Фиксед колонки(справа и слева), фиксед хидер из самого сложнореализуемого. Добавляемая строчка суммы, роу- и кол- спаны, экспанд роу, автоматическая индексная колонка, колонка с чекбоксами, ресайз колонок, ширина колонок(при всей простоте, несовсем линейная реализация), ну и много можно дальше перечислять и не говоря уж о куче нужных и удобных ивентов. Так что не надо ее нивелировать — функционала просто уйма! не так просто его будет реализовать и уж точно не за несколько дней. Я только об этом. Глубокого смысла повторять не вижу, но если вам удастся повторить данный функционал и будет более производительной, то я только за.
А до уровня функциональности их таблицы я на днях доведу
Думаете это получится так быстро? У них там целая команда работает) А так да, видел их исходники конечно, даже добавлял функциональность(так же фиксил небольшие баги), которую мне не хватала, так же являюсь контрибутором данного проекта. Незнаю что тут можно придумать другого для производительности, но перерендер каждой ячейки это жестоко, если бы механизм более точечного обновления, может быть это бы помогло с производительностью, но с другой стороны без рендера каждой ячейки не добиться такого функционала. У меня ситуация, что я сделал на ее основе таблицу с инфинити скролом и при пролистывании до 100-200 страниц конечно все начинает жутко лагать. с пейджингом хоть по 50 строк более или менее нормально.
Чем использую таблицу на элементе. Вы считаете, что у вас получится сделать более производительную таблицу, если накрутить весь то функционал, который есть в оригинальной таблице?
>>Redux при желании можно прикрутить без проблем и к Polymer, хотя вы явно в курсе, у вас статья про это есть.
А думаете почему я так относительно быстро перешел на vue? Потому что бизнес-логика была уже реализована, и оставалось обернуть ее во vue.
А я как раз в polymer разочаровался, в виду выясненных багов с dom-repeat, и фризы при реализации конкретного проекта на нем. Позже весь проект переписал на vue(дабы вся логика была зашита в редакс), и теперь радуюсь — данные проблемы производительности ушли. Но хотя полимер по своему хорош, но vue все таки лучше.
Есть мнение(не мое) в поддержку джейкыери для основы проекта — «Все библиотеки и фрайемворки уйдут в не бытиё, а jq останется». Насколько оно справедливо, покажет время, но пока почему-то у меня вызывает улыбку.
Согласен, есть разница между v-model(двусторонний бинд) и :value(односторонний). И может не совсем удачный пример именно с инпутом. Но это не отменяет того, что есть компоненты, с которыми такое не пройдет без подавления внутренних ивентов. Например, jsfiddle.net/4zufmzvf, в этом примере прибинденное проперти меняется только непосредственно вручную, с подавлением ивентов, и в данном случаи уже без разницы это :value или v-model.
Это, как понимаю, настройка CI. Но что за правило? Как jest говорит, что произошла деградация покрытия? Для этого же надо сравнить покрытие с предыдущим значением...
Спасибо за комментарий. В этом случаи какой механизм будет блокировки ПРа будет, поясните, пожалуйста?
)))
Фиксед колонки(справа и слева), фиксед хидер из самого сложнореализуемого. Добавляемая строчка суммы, роу- и кол- спаны, экспанд роу, автоматическая индексная колонка, колонка с чекбоксами, ресайз колонок, ширина колонок(при всей простоте, несовсем линейная реализация), ну и много можно дальше перечислять и не говоря уж о куче нужных и удобных ивентов. Так что не надо ее нивелировать — функционала просто уйма! не так просто его будет реализовать и уж точно не за несколько дней. Я только об этом. Глубокого смысла повторять не вижу, но если вам удастся повторить данный функционал и будет более производительной, то я только за.
Думаете это получится так быстро? У них там целая команда работает) А так да, видел их исходники конечно, даже добавлял функциональность(так же фиксил небольшие баги), которую мне не хватала, так же являюсь контрибутором данного проекта. Незнаю что тут можно придумать другого для производительности, но перерендер каждой ячейки это жестоко, если бы механизм более точечного обновления, может быть это бы помогло с производительностью, но с другой стороны без рендера каждой ячейки не добиться такого функционала. У меня ситуация, что я сделал на ее основе таблицу с инфинити скролом и при пролистывании до 100-200 страниц конечно все начинает жутко лагать. с пейджингом хоть по 50 строк более или менее нормально.
Какого рода?
А думаете почему я так относительно быстро перешел на vue? Потому что бизнес-логика была уже реализована, и оставалось обернуть ее во vue.
А так подробности здесь.