Спасибо за полезную статью, я бы еще добавил маленький пункт про разницу описания методов через прототип (1 хуже по памяти чем 2 и 3, тк создает каждый раз функцию для поля bar)
function Foo() {
this.bar = function() {}
}
function Foo() {
}
Foo.prototype.bar = function() {}
class Foo {
bar() {}
}
Последнее время, может быть я ошибаюсь, но большинство разработчиков на JavaScript (особенно на React) почему-то боятся слов class , constructor :)
Логгеры есть (девтулзы), но зачем они нужны, когда можно по стектрейсу встроенных девтулзов в сам браузер найти причину изменений, а некоторые браузеры даже группируют события в стектрейсе по MobX (на скрине zen браузер)
А как обстоят дела с созданием динамических сторов в redux ? С реализацией MVVM паттерна ? Или аналогов библиотеки mobx-web-api (утилиты для реактивной работы с веб апи браузера)?
От себя добавлю, что я перестал пользоваться barel файлами, поэтому проблем с циклическими импортами стало на порядок меньше.
Пользу от barel файлов вижу лишь частично, потому что их наличие никак не блокирует физически импортировать модуль в обход баррель файла, а красивость импортов не имеет какой то ценности
серьёзно ?) Rx будут больше понимать как работает, чем Mobx?) В корне с вами не согласен, конечно все зависит от как пишется код на MobX ( если mst то да каша), а обычные классы, свойства, фукнции и в целом код приближенный к обычному JS - будет намного понятнее чем RxJS
Например? Берём недавнюю статью про FEOD (https://habr.com/p/972410/) и там точно также возникает много вопросов о том что где и как должно лежать. И это мы говорим про хранение файлов и структуру папок в контексте архитектурных методологий / принципов
Берём, например, DDD. По ней, не знаю как у вас, но у меня возникает очень много вопросов в контексте организации кодовой базы.
Поэтому, я считаю, что у всего будут вопросы, главное на них просто отвечать, придерживаясь документации по тем принципам, которые используешь.
Другое дело, когда мейнтейнеры FSD сами не знают где и что должно лежать. Вспомнил, как пару лет назад, я спрашивал где мне расположить компонент Layout, который использовал виджеты, и который использовался на страницах, ну и на такой вопрос, не нарушая принципов FSD нельзя ответить
В итоге это приведет к тому (же почему FSD начал продвигать pages-first подход), что, открывая pages/users - всё содержимое этой страницы будет разбросано по всем другим слоям, что имхо, считаю проблемой
И эта архитектурная методология, которая накладывает тоже определённые ограничения, также как и FSD, будет вызывать много споров и вопросов.
Читая данную статью, у меня возник вопрос по поводу роутеров. Если импорты между pages и из app запрещены, тогда как пользоваться атомарным роутами во фронтенд приложениях?
Данный роут, обычно я размещаю на уровне pages/products чтобы он лежал в том месте, к чему он относится. Соответственно, чтобы навигироваться то нужно этот роут импортировать, а по правилам FEOD нужно конфигурацию прутов выносить в global , или же в app/routing (но при этом нельзя оттуда импортировать)
Как раз таки наоборот, реакт компоненты перерендериваются почти на каждый чих. Конечно если оборачивать компоненты в observer из MobX или memo из React то такого не будет
Недавний реакт конф показал что сигналы это не серебряная пуля и не мана небесная, конечно непонятно какие разрабы реакта имели в виду сигналы.
Уменьшить количество ререндеров и добиться гранулярных ререндеров можно добиться и так с помощью MobX, до сих пор не понимаю почему люди так боятся этой библиотеки, что вновь и вноаь изобретают что то )
Так и не понял зачем нужно было уходить от MobX, если можно было заюзать одну из опенсорс либ интеграции MobX с tanstack query (например mobx-tanstack-query).
В итоге уйдя от МобХ вы будете прибивать бизнес логику к механизмам рендеринга , тем самым подшивать бизнес логику в слой представления.
Не знал что приватные поля уже давно имеют хорошую поддержку во всех браузерах!
Большинство в действительности пользуются TypeScript, а там есть красивое ключевое слово private
Не соглашусь с автором оригинальной статьи что SSR это must have только потому что классические SPA "устарели"
До сих пор очень много делают SPAшек без SSR решая огромное количество тяжёлых задач.
На счёт фабричных ключей для танстак кверей соглашусь - вещь полезная, но в идеале конечно это через кодогенератор разруливать
Спасибо за полезную статью, я бы еще добавил маленький пункт про разницу описания методов через прототип (1 хуже по памяти чем 2 и 3, тк создает каждый раз функцию для поля bar)
Последнее время, может быть я ошибаюсь, но большинство разработчиков на JavaScript (особенно на React) почему-то боятся слов
class,constructor:)Логгеры есть (девтулзы), но зачем они нужны, когда можно по стектрейсу встроенных девтулзов в сам браузер найти причину изменений, а некоторые браузеры даже группируют события в стектрейсе по MobX (на скрине zen браузер)
А как обстоят дела с созданием динамических сторов в redux ? С реализацией MVVM паттерна ? Или аналогов библиотеки mobx-web-api (утилиты для реактивной работы с веб апи браузера)?
Отлично с этим у mobx, есть привязка к tanstack-query, который умеет на голову выше, чем rtk-query
Полезная статья, спасибо!
От себя добавлю, что я перестал пользоваться barel файлами, поэтому проблем с циклическими импортами стало на порядок меньше.
Пользу от barel файлов вижу лишь частично, потому что их наличие никак не блокирует физически импортировать модуль в обход баррель файла, а красивость импортов не имеет какой то ценности
серьёзно ?) Rx будут больше понимать как работает, чем Mobx?)
В корне с вами не согласен, конечно все зависит от как пишется код на MobX ( если mst то да каша), а обычные классы, свойства, фукнции и в целом код приближенный к обычному JS - будет намного понятнее чем RxJS
Самописный SSR или HTMX, все зависит от требований.
Поэтому я и не использую next, и только слышу как все от него плюются.
Брать инструмент, по сути фреймворк, чтобы его чинить/допиливать, не очень хочется брать в продакшн проект
Например? Берём недавнюю статью про FEOD (https://habr.com/p/972410/) и там точно также возникает много вопросов о том что где и как должно лежать. И это мы говорим про хранение файлов и структуру папок в контексте архитектурных методологий / принципов
Берём, например, DDD. По ней, не знаю как у вас, но у меня возникает очень много вопросов в контексте организации кодовой базы.
Поэтому, я считаю, что у всего будут вопросы, главное на них просто отвечать, придерживаясь документации по тем принципам, которые используешь.
Другое дело, когда мейнтейнеры FSD сами не знают где и что должно лежать. Вспомнил, как пару лет назад, я спрашивал где мне расположить компонент Layout, который использовал виджеты, и который использовался на страницах, ну и на такой вопрос, не нарушая принципов FSD нельзя ответить
Думаю если взять другие методологии, то будет тоже очень много вопросов, на которые требуется ответить.
В целом аналогично можно сказать и про разные архитектуры. Но это же не будет значит, что все архитектуры говно ?
Просто сложнее писать)
В итоге это приведет к тому (же почему FSD начал продвигать pages-first подход), что, открывая
pages/users- всё содержимое этой страницы будет разбросано по всем другим слоям, что имхо, считаю проблемойИ эта архитектурная методология, которая накладывает тоже определённые ограничения, также как и FSD, будет вызывать много споров и вопросов.
Читая данную статью, у меня возник вопрос по поводу роутеров. Если импорты между pages и из app запрещены, тогда как пользоваться атомарным роутами во фронтенд приложениях?
Пример:
Данный роут, обычно я размещаю на уровне pages/products чтобы он лежал в том месте, к чему он относится. Соответственно, чтобы навигироваться то нужно этот роут импортировать, а по правилам FEOD нужно конфигурацию прутов выносить в global , или же в app/routing (но при этом нельзя оттуда импортировать)
Как раз таки наоборот, реакт компоненты перерендериваются почти на каждый чих.
Конечно если оборачивать компоненты в observer из MobX или memo из React то такого не будет
Недавний реакт конф показал что сигналы это не серебряная пуля и не мана небесная, конечно непонятно какие разрабы реакта имели в виду сигналы.
Уменьшить количество ререндеров и добиться гранулярных ререндеров можно добиться и так с помощью MobX, до сих пор не понимаю почему люди так боятся этой библиотеки, что вновь и вноаь изобретают что то )
Ждём появления новых крутых хуков из разряда
useVercelPerfBoost(API_TOKEN)
useCallstackServerState()
Так и не понял зачем нужно было уходить от MobX, если можно было заюзать одну из опенсорс либ интеграции MobX с tanstack query (например mobx-tanstack-query).
В итоге уйдя от МобХ вы будете прибивать бизнес логику к механизмам рендеринга , тем самым подшивать бизнес логику в слой представления.
Хорошо, зайдём на огонёк)