Pull to refresh
5
0
Vitaliy @Ni55aN

User

Send message
тоже пришел к выводу, что Styled-components с TypeScript в плане DX удобнее и эффективнее, чем препроцессоры. Из коробки решаются те проблемы, которые в каких либо пост/препроцессорах решается установкой 100500 плагинов
Как по мне, по возможности лучше вообще избегать subscribe() и компоновать все Observable через pipe. Если все же придется обмазываться ручными подписками — использовать @ngneat/until-destroy
в чистом JS можно добиться относительно бедного статического анализа через тот же ESLint. Если пойти дальше, можем использовать TS. С ним тоже будет некоторая пропасть, но это хотя бы решает такую дилемму как:
1. установить 100500 модулей для проверки CSS и 100500 модулей для проверки JS/TS
или
2. установить 100500 модулей для проверки JS/TS
какой-то непонятный кейс. Почему они должны устанавливать это у себя через самописный установщик? Какая у них инфраструктура и на чем запускается? Почему бы не настроить CI/CD с использованием Docker'а?
Если отталкиваться от компонентной архитектуры, то зачем вообще нужны эти пляски с каскадами?
Селекторы придумай, за их специфичностью проследи, статический анализ достигается только подключением 100500 плагинов на все случаи жизни, базирующиеся на данных из JS стили создаются через красивые хитрые решения

Конечно, все еще зависит от инструментов. Конечно, без них никуда.
Допустим, возьмем React.js. Тогда смело можно использовать какой-то CSS-in-JS, например styled components, и по возможности вообще избегать вложенных селекторов и декларации className где-либо, что сразу избавляет от пропасти в статическом анализе и каких либо мега инструментов для удаления мертвого CSS, и многое другое реализуется средствами JS, что избавляет нас от каких-либо препроцессоров, которые пытаются повторить то же самое, что уже умеет JS, и то на момент сборки.

Конечно, можно аргументировать около олдскульные подходы и трюки в CSS тем, что они менее требовательны к ресурсам, но давайте еще помнить о вреде низкоуровневых оптимизаций, так как в <ваш процент>% случаев они не играют никакой роли. Как минимум, lazy loading и разбитие бандла на части даст больше профита, чем попытки сжать итоговый CSS

И в конце концов, CSS создавали не люди, которые прилетели из будущего и уже знают, какое недостатки будет иметь в будущем такая реализация
за что создателям Rete отдельное спасибо!

Как неожиданно и приятно))
Есть шанс, что появится альтернатива Ember-like условному рендерингу, циклам и прочему? Имхо подобные конструкции в виде директив выглядят более читаемыми, не создавая лишние вложенности.
В некоторых кейсах такой глобальный сервис не подойдет, почему бы сразу не сделать это через DI? Допустим, пробросить экземпляр в провайдер Context API, причем только на необходимом уровне иерархии. В итоге, приходим к том, что уже давно умеет Angular и Vue
Reversed Depth Buffer достаточно хорошо решает проблему с Z-fighting. Если кратко, то он избавляет от сильных потерь точности float (а чем больше значение, тем меньше точность после точки)
чтобы не усложнять, сделал пунктирными линиями, так как в svg добавить тень простым свойством не получится, а усложнять не хочется. Хотя так, имхо, неплохо смотрится.

Есть один баг: определяет узлы правильно, но почему-то не меняется стили для всех. Исправляю
кто знает на сколько будет полезным чтение данных о схеме в текстовом виде, поэтому пока сосредоточился на чисто графическом выделении изменений.
Пример: codepen.io/Ni55aN/full/POWEvm
Правая часть редактируемая, внизу выбирается то, что нужно подсвечивать
мне не особо понятно что описывается в схеме)) В таких данных кроме логики и представление хранится?

Пока сделал такой пример: codepen.io/Ni55aN/full/POWEvm
В нем можно подсвечивать узлы, которые удалены/добавлены/перемещен или в них изменены данные. Правая часть редактируемая

Еще сделаю подсветку соединений. Пока как не крутил, в таком виде получилось более приятно для восприятия (имхо).
Возможность выбора нескольких узлов присутствует, а что касается подобного функционала, то вполне реально такое сделать в качестве надстройки над библиотекой, уже при создании конкретного редактора.

Вы имеете в виду что-то вроде UML? Есть только простые диаграммы и mindmap'ы, нарисованные на скорую руку. Но может есть какие-то сервисы для создания диаграмм классов из JS
Реальное применение модулей: ni55an.github.io/allmatter
В показательном примере (который откроется автоматически) есть узел Module, а в нем вложены узлы для создания цветной текстуры. Кроме этого, можно делать неограниченное вложение самих модулей (пример в Hub'е)
С помощью Rollup собираю, с использованием плагинов Babel и плагина для встраивания pug. А также отдельно транслируются SASS в CSS. Все это собирается через npm run build, но перед этим нужно не забыть установить зависимости (npm install)
узел, который инкапсулирует в себе графы/схемы. Как показано в примере, можно вынести некоторые инструкции с целью декомпозиции. Сам модуль может содержать такие же схемы, только с определенными узлами для входа/выхода
чей аргумент «с чтением»? Мною было предложено только использование vcs, чтобы хотя бы коммитить изменения. Если построчно сравнивать, то это вполне реально, но не думаю что в перспективе будет полезно. Так выглядят данные

Вьювера я пока не находил удобного. Вопрос с этим буду решать, может что подскажут
1. json для хранения, схема для всего остального
2. сам json читать не нужно. Повторюсь, он нужен только для хранения, а функционал diff'а и подобное любой может сделать так, как пожелает
1

Information

Rating
Does not participate
Registered
Activity