...В свободное время... учить Битрикс... Да ещё и после Laravel... А вы знаете толк в извращениях!
До стх пор помню тот момент, когда после Битрикса попробовал Yii — этот странный восторг от того, что прямо на твоих глазах творится настоящая магия вместо привычной битриксовой имитации.
Имхо, Битрикс — прекрасный трамплин для маркетологов: вот они-то там точно получают мастер-класс. Для программиста же это лимбо.
Для полноты истории не хватает постскриптума, что через год-два клиенту пришлось обращаться к другой фирме и таки писать свой инструмент с нуля и по всем правилам. Потому что количество человекочасов на каждое новое расширение поделия Серёжи увеличивалось в геометрической прогрессии, и то, что раньше стоило 4 часа, теперь стоит все 40, а то и 80.
1) А как у вас npm install без actions/setup-node работает?
2) Если использовать actions/setup-node, то необходимости вызывать команду echo "//registry.npmjs.org/:_authToken=$NPM_TOKEN" >> .npmrcнет, т.к. экшн это делает по-умолчанию. Разве что переменная называется NODE_AUTH_TOKEN.
Импорты в ES2015+ существуют в таком виде потому что это необходимо браузерам для статического анализа файла и предзагрузки файлов-зависимостей. Только после этого происходит выстраивание полного AST программы, и начинается компиляция в байт-код. Именно поэтому не подходят варианты in situ, как в PHP или Java, именно поэтому отказались и от нодовского require, который подгружал файл-зависимость прямо на месте. И именно поэтому динамический импорт (который import()) — асинхронный.
Что касается использования файловой системы вместо модульной, то причина всё та же — браузер изначально работает с URL, что позволяет делать вот такие штуки:
import confetti from 'https://cdn.skypack.dev/canvas-confetti';
Как вы понимаете, сделать такое с модульной системой Java или PHP нереально — потребуется пакет-менеджер, в то время как JS успешно работает вообще без него. Можете взглянуть на Deno для примера.
состояние изменяется только с помощью чистых функций — операций (actions);
Маленькая поправочка: чистыми функциями в Redux являются, конечно же, редьюсеры, а не экшны. Экшн — это просто объект с данным, там никаких функций нет.
Набыдлокодить можно с чем угодно. И MobX/Redux Saga etc тут не спасут никак.
Там не "сильно много". Там "тьма" бойлерплейта.
Если по примеру рекомендаций в документации класть константы в один файл, редьюсеры в другой, а action creator-ы в третий — тогда да, чёрт ногу сломит, и довольно быстро. Не понимаю этого функционального деления. А если делить логически, то получаются небольшие аккуратные файлы, которые вряд ли будут больше классов MobX. Я ж говорю, всё зависит от прямоты рук.
Вы так говорите, как будто я его никогда не использовал ) Конечно, в курсе. Вот только нужен ли он? Зависит от задачи. Иногда проще считать данные прямо на месте, через useMemo.
К слову, реселект весит всего 800 байт, так что в плане размера всё довольно неплохо.
Не дальновидный аргумент. А вместе со всякими сагами, ресектами и прочими библиотеками, которые необходимо использовать с Redux, те же 2.5kb останутся?
Честно скажу, что саги, реселекты etc точно так же не особо приветствую. По-моему, самое лучшее — это thunk и голый редакс. И нет, не могу сказать, что там сильно много бойлерплейта получается. Всё, как всегда, зависит от правильной структуры.
С появлением react хуков, это странно читать.
Ну, здесь речь изначально шла о Redux vs MobX. Но моё мнение, что да, с хуками всё та же проблема. У реакта и реакт-комьюнити почему-то большая склонность к магии в целом.
Те же саги — так и не понял их смысл. Санки и работают, и тестируются не хуже (а то и лучше). А весит эта библиотека что твой самолёт.
В общем-то, поэтому-то мне и нравится storeon — мало того, что он весит 180 байт, так ещё и простой как табуретка, и никаких дополнительных приблуд ему не нужно. Всё, что нужно, сразу есть.
Ну и мне, честно говоря, не понятно, что именно многие в MobX называют магией? Использовать обертку для наблюдения за изменением данных или что-то другое?
Ну, в целом, да, у меня первой вспоминается именно Observable Arrays. Помню, у меня довольно сильно подгорело, когда пришлось каждый раз этот дурацкий массив туда-сюда преобразовывать. При том, что Array.from тогда не сильно ещё использовался.
Вторым, кстати, был autorun. Именно с ним было связано моё впечатление, что с MobX тяжелее сделать что-то нестандартное.
Во-первых, MobX в 7 раз толще Redux (15kb vs 2.5kb по версии Bundlephobia).
Во-вторых, при попытке сделать с ним что-то нестандартное он просто взрывается (ну, по крайней мере так было года три назад, когда я последний раз его трогал).
Ну и вообще, чем меньше магии, тем проще работать с инструментом. MobX в этом смысле магией забит под завязку. А где магия — там и костыли (Observable Arrays всё ещё там используются?)
Хотя, конечно, среди всех менеджеров состояния мой личный выбор — это вообще storeon. Маленький, но при этом мощный и ничем не уступает Redux, а где-то даже превосходит.
Первый вариант (2015 года) имел слишком малые возможности, а две последующих версии забраковали из-за проблем с оптимизацией в JS-движках. Из-за того, что декораторы про факту меняют базовую структуру класса, все оптимизации, построенные на статическом анализе структуры класса, рассыпаются, и в результате получается, что класс с декоратором работает в несколько раз медленнее, чем класс без декоратора. Ещё важно учитывать возможность транспайлинга декораторов: например, третья версия внесла очень большую сложность для Babel, и в конечном итоге была отклонена в том числе и по этой причине.
Нынешняя (четвёртая) редакция учитывает все проблемы предыдущих, так что, будем надеяться, в этот раз всё пройдёт хорошо, и мы, наконец, увидим декораторы в JS.
Превосходно, позвольте вам поаплодировать. А что насчёт пользователей? Реакт уже обогнали?
Ох не вам говорить о побеге от реальности... Сколько вы уже со своим $mol-ом носитесь? 6 лет, 7? А воз и ныне там
А почему ни слова о
@preact/signalsв 2024?Всё-таки есть что-то неизменное в наше время. Во всём мире уже началась эпоха ИИ, а авторы битрикса всё так же мощно пытаются в рефакторинг...
...В свободное время... учить Битрикс... Да ещё и после Laravel... А вы знаете толк в извращениях!
До стх пор помню тот момент, когда после Битрикса попробовал Yii — этот странный восторг от того, что прямо на твоих глазах творится настоящая магия вместо привычной битриксовой имитации.
Имхо, Битрикс — прекрасный трамплин для маркетологов: вот они-то там точно получают мастер-класс. Для программиста же это лимбо.
Для полноты истории не хватает постскриптума, что через год-два клиенту пришлось обращаться к другой фирме и таки писать свой инструмент с нуля и по всем правилам. Потому что количество человекочасов на каждое новое расширение поделия Серёжи увеличивалось в геометрической прогрессии, и то, что раньше стоило 4 часа, теперь стоит все 40, а то и 80.
Фрейд и Юнг в 2021? Серьёзно?
1) А как у вас
npm installбезactions/setup-nodeработает?2) Если использовать
actions/setup-node, то необходимости вызывать командуecho "//registry.npmjs.org/:_authToken=$NPM_TOKEN" >> .npmrcнет, т.к. экшн это делает по-умолчанию. Разве что переменная называетсяNODE_AUTH_TOKEN.Импорты в ES2015+ существуют в таком виде потому что это необходимо браузерам для статического анализа файла и предзагрузки файлов-зависимостей. Только после этого происходит выстраивание полного AST программы, и начинается компиляция в байт-код. Именно поэтому не подходят варианты in situ, как в PHP или Java, именно поэтому отказались и от нодовского
require, который подгружал файл-зависимость прямо на месте. И именно поэтому динамический импорт (которыйimport()) — асинхронный.Что касается использования файловой системы вместо модульной, то причина всё та же — браузер изначально работает с URL, что позволяет делать вот такие штуки:
Как вы понимаете, сделать такое с модульной системой Java или PHP нереально — потребуется пакет-менеджер, в то время как JS успешно работает вообще без него. Можете взглянуть на Deno для примера.
Маленькая поправочка: чистыми функциями в Redux являются, конечно же, редьюсеры, а не экшны. Экшн — это просто объект с данным, там никаких функций нет.
Набыдлокодить можно с чем угодно. И MobX/Redux Saga etc тут не спасут никак.
Если по примеру рекомендаций в документации класть константы в один файл, редьюсеры в другой, а action creator-ы в третий — тогда да, чёрт ногу сломит, и довольно быстро. Не понимаю этого функционального деления. А если делить логически, то получаются небольшие аккуратные файлы, которые вряд ли будут больше классов MobX. Я ж говорю, всё зависит от прямоты рук.
Вы так говорите, как будто я его никогда не использовал ) Конечно, в курсе. Вот только нужен ли он? Зависит от задачи. Иногда проще считать данные прямо на месте, через useMemo.
К слову, реселект весит всего 800 байт, так что в плане размера всё довольно неплохо.
С прокси, наверное, вполне нормально, но когда там был объект, изображающий из себя массив, было больно )
Честно скажу, что саги, реселекты etc точно так же не особо приветствую. По-моему, самое лучшее — это thunk и голый редакс. И нет, не могу сказать, что там сильно много бойлерплейта получается. Всё, как всегда, зависит от правильной структуры.
Ну, здесь речь изначально шла о Redux vs MobX. Но моё мнение, что да, с хуками всё та же проблема. У реакта и реакт-комьюнити почему-то большая склонность к магии в целом.
Те же саги — так и не понял их смысл. Санки и работают, и тестируются не хуже (а то и лучше). А весит эта библиотека что твой самолёт.
В общем-то, поэтому-то мне и нравится storeon — мало того, что он весит 180 байт, так ещё и простой как табуретка, и никаких дополнительных приблуд ему не нужно. Всё, что нужно, сразу есть.
Ну, в целом, да, у меня первой вспоминается именно Observable Arrays. Помню, у меня довольно сильно подгорело, когда пришлось каждый раз этот дурацкий массив туда-сюда преобразовывать. При том, что Array.from тогда не сильно ещё использовался.
Вторым, кстати, был autorun. Именно с ним было связано моё впечатление, что с MobX тяжелее сделать что-то нестандартное.
Да чего вы так возбудились-то, будто я у вас священную корову только что отобрал :D
Предлагаете пример с вас брать? Вы-то тут так много пруфов привели, что я снимаю шляпу :D
Мне становится жаль пользователей вашего продукта.
"Лол, шта?? Как обычно — пустые слова без конкретики"
Слова про Observable Arrays вы, видимо, специально игнорируете ))
Спасибо, заберите обратно :D
А я вот считаю с точностью до наоборот :)
Хотя, конечно, среди всех менеджеров состояния мой личный выбор — это вообще storeon. Маленький, но при этом мощный и ничем не уступает Redux, а где-то даже превосходит.
Первый вариант (2015 года) имел слишком малые возможности, а две последующих версии забраковали из-за проблем с оптимизацией в JS-движках. Из-за того, что декораторы про факту меняют базовую структуру класса, все оптимизации, построенные на статическом анализе структуры класса, рассыпаются, и в результате получается, что класс с декоратором работает в несколько раз медленнее, чем класс без декоратора. Ещё важно учитывать возможность транспайлинга декораторов: например, третья версия внесла очень большую сложность для Babel, и в конечном итоге была отклонена в том числе и по этой причине.
Нынешняя (четвёртая) редакция учитывает все проблемы предыдущих, так что, будем надеяться, в этот раз всё пройдёт хорошо, и мы, наконец, увидим декораторы в JS.
Какая-то детская викторина на уровне "Читал до я доки на MDN и reactjs.org", ни одного действительно интересного и нетривиального вопроса
А почему преобразование в реальный Array сделано через
Array.prototype.slice, а не через стандартныйArray.from?А у меня вопрос: как вы без Typescript спустя год помните, что вообще должно вам с сервера прийти?