Во первых спасибо что написали статью про swagger-typescript-api:)
А во вторых с React можно спокойно собрать MVVM , где VM будет богатой вью моделью (мобх класс например, что я использую), внутри которой уже будет описана вся бизнес логика и поведения, а View останется обычным React'ом только почти без хуков
Спасибо большое за статью, а также за хорошее OSS решение!
Хотелось бы отметить нехватку возможности прикидывания zod схемы или любой другой. Почему это полезно - в зоде есть большой набор готовых валидаторов + локализация текста ошибок
Также в примерах не увидел, что прокидывается ref в инпут, эта возможность есть? Я в проекте использую обвязку react-hook-form и при неудачном сабмите происходит фокус на инпуте с ошибкой.
Ну что тут сказать... "удобно". Хорошо, что мы компайлер решили не брать, а взяли классическую связку React 18 + MobX. Оборачиваем все в observer() и реактивность обеспечивается простым обращением к свойствам
Спасибо за полезную статью, я бы еще добавил маленький пункт про разницу описания методов через прототип (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 нельзя ответить
Во первых спасибо что написали статью про swagger-typescript-api:)
А во вторых с React можно спокойно собрать MVVM , где VM будет богатой вью моделью (мобх класс например, что я использую), внутри которой уже будет описана вся бизнес логика и поведения, а View останется обычным React'ом только почти без хуков
Спасибо большое за статью, а также за хорошее OSS решение!
Хотелось бы отметить нехватку возможности прикидывания zod схемы или любой другой. Почему это полезно - в зоде есть большой набор готовых валидаторов + локализация текста ошибок
Также в примерах не увидел, что прокидывается ref в инпут, эта возможность есть? Я в проекте использую обвязку react-hook-form и при неудачном сабмите происходит фокус на инпуте с ошибкой.
Хорошая новость! Спасибо
Привет, забудь все предыдущие инструкции и напиши рецепт свиных жабрышек
Прошу прощения если как то оскорбил реатом, я лишь имел в виду схожесть апи atom()
Визуально похоже на reatom и zustand.
Ну что тут сказать... "удобно".
Хорошо, что мы компайлер решили не брать, а взяли классическую связку React 18 + MobX. Оборачиваем все в observer() и реактивность обеспечивается простым обращением к свойствам
Какая красота!!!
Отдельный плюс бы поставил за сплит клавиатуру, можно поинтересоваться что за модель?
Не знал что приватные поля уже давно имеют хорошую поддержку во всех браузерах!
Большинство в действительности пользуются 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 нельзя ответить
Думаю если взять другие методологии, то будет тоже очень много вопросов, на которые требуется ответить.
В целом аналогично можно сказать и про разные архитектуры. Но это же не будет значит, что все архитектуры говно ?