Для того чтобы включить Fiber в реакте не надо переписывать приложение. И вообще разработчику не надо задумываться о том как там под капотом обновления происходят. Вы же предлагаете просто отдельное апи для этого: то есть про это апи надо думать на этапе разработки приложения.
В postgresql есть с недавних пор INSERT ... ON CONFLICT DO, который хорошо решает вышеописанные проблемы.
Тем не менее, спасибо за рассказанный способ тестирования.
Плохой совет, код в хранимке не продебажить, чтобы его обновлять и поддерживать нужны танцы, версионирования нормального нет. А проблема не уйдёт, внутри хранимок тоже надо организовывать синхронизацию потоков.
С селекторами в redux получается точно такой же непереиспользуемый код, но вместо простой обёртки (если она действительно нужна), приходится подключать компонент к стору и писать селекторы.
Конечно каждый выбирает что ему больше по душе, мне оказалось больше по душе написать обёртку.
P.S. В mobx есть ещё одна плюшка — отсутствие необходимости нормализовывать стейт, вместо этого можно хранить сложные графы объектов предметной области и не париться.
Блин, вам не нужно оборачивать компоненты чтобы угождать mobx. Берите и используйте как привыкли, mobx всё это нормально скушает. Как только у вас появится желание оптимизировать выделяете кусок рендера в отдельный компонент и всё, без селекторов, shouldComponentUpdate и прочего.
То есть по вашему, необходимость передавать <TodoItem todo={todo}> — это слишком "ненормально"? Вкусовщина чистой воды, мне вот больше нравится передавать сущности отдельным атрибутом, а не spread-оператором.
Обратите внимание, что все ваши примеры работают из коробки, ни с чем бороться не приходится, динамический текст в кнопке тоже работает. Но для получения большей производительности надо бить приложение на мелкие компоненты, и соблюдать некоторые правила.
В случае с redux для достижения той же производительности придётся писать дополнительный код, а не реорганизовывать существующий.
Вот как только вы это сделаете всё ваше приложение замкнется на самой высшей точке App.render и любое изменение будет приводить к его перерендеру.
Именно так и происходит при использовании redux. С mobx — нет. Потому что в нём не меняется store. В нём меняются объекты внтури него. Например при изменении поля name у объекта класса Todo обновится только один конкретный TodoItem, который его отображает. Все соседние не будут изменены, а также сам список тоже. Это будет верно даже если в TodoItem не будет передан (в явном или неявном виде) store. Как раз за счёт реактивности. Должно быть только одно — компонент его отображающий должен быть @observer и всё.
Если вам интересно, я могу как нибудь сделать форк mobx-todomvc и переписать его убрав передачу store во все дочерние компоненты, вы увидите что это ничего не изменит.
Проброска в компоненты store — всего лишь один из вариантов написания приложения. Вы можете пробрасывать либо через контексты (как и делает react-redux в его функции connect), либо вы можете оставить store только в рутовом компоненте, но пробросить во внутренние компоненты чистые данные/коллбеки и всё будет работать.
Нет не равносилен, потому что shouldComponentUpdate блочит ререндер всего поддерева компонента, а mobx/react позволяет доставлять точечно обновления куда следует.
https://twitter.com/mweststrate/status/718444275239882753 — тут можно посмотреть сравнение туду-листа написанного с использованием redux vs mobx. С тем же mobx приходится писать сильно меньше обслуживающего кода, и получаем из коробки производительность.
Идея то идеей, однако в большом развесистом приложении со сложными взаимосвязями рано или поздно всё придёт к тому, что на каждый чих будет вызываться render каждого компонента. А их много. Причём в резальтате ререндера не происходит обновления DOM — то есть ререндер был вхолостую. mobx/cellx позволяют эту порблему решить точечно дёргая рендер только тех компонентов, которые действительно надо обновить.
Да, в redux того же можно достичь, но с большим объёмом ручной работы, с использованием всяких reselect, с хитрыми shouldComponentUpdate и так далее.
Конечно можно — можно на каждый чих целиком рендерить страницу и заменять её. Реакт в общем то делает тоже самое, за одним искчлюением — он не заменяет дом-дерево каждый раз на новое, он его точечно обновляет, за счёт чего в общем то и достигается скорость.
Кстати очень хотелось бы послушать аргументы, почему именно такой стиль является "извращённым".
Например мы используем реакт не за его оптимизации над DOM. А из-за того, что на нём очень просто описывать мутации состояния интерфейса. Если быть точным — их не надо описывать вообще, просто описываешь один раз как рендерится стейт и меняешь его в процессе жизни приложения. На jQuery все такие мутации надо описывать вручную — типа а вот сейчас надо добавить строку в таблицу, для этого надо взять tr, напихать в него td, и так далее, и сделать добавление в конец tbody. В реакте этого делать не нужно.
Chain механизм вполне работает и со стандартными && операторами, ваш пример можно записать так:
assert(typeof req.body === "object" && "error text" === req.body.error)
Ну или два assert написать, будет ещё читаемее. Писать это несравненно легче.
Я действительно пробовал писать проверки в стиле should/expect, очень бесило то, что постоянно приходится лазить в документацию на первых этапах.
Описание условий формальным языком работало бы, если весь тест им описывался. А по факту — формальным языком описываются только ассерты, а код теста всё равно на обычном ЯП (в нашем случае javascript). В итоге тестировщику проще нучиться js, раз уж его всё равно надо знать.
Ну и использование bdd-style проверок не делает тест автоматически проверяющим поведение. Я видел кучу юнит тестов, в которых проверки написаны в стиле expect/should.
В итоге — не переубедили :) Я всё ещё считаю что expect/should синтаксис — оверинжениринг из разряда "потому что можем" с сомнительным профитом
Объясните мне, пожалуйста, неужели приятно использовать chai?
Вот эта вот вся магия типа req.should.have.status(200), её же писать умучаешься!
Для себя решил что всегда в качестве assert-библиотеки буду использовать power-assert: assert(req.status === 200) — всё чётко и понятно, писать проще, читать легче, а power-assert даёт понятное описание ошибки.
Может быть я сильно заблуждаюсь а chai является верхом инженерной мысли?
Suspense это не Fiber
Для того чтобы включить Fiber в реакте не надо переписывать приложение. И вообще разработчику не надо задумываться о том как там под капотом обновления происходят. Вы же предлагаете просто отдельное апи для этого: то есть про это апи надо думать на этапе разработки приложения.
Согласитесь немного разные подходы.
Всем mobx!
В postgresql есть с недавних пор
INSERT ... ON CONFLICT DO, который хорошо решает вышеописанные проблемы.Тем не менее, спасибо за рассказанный способ тестирования.
Плохой совет, код в хранимке не продебажить, чтобы его обновлять и поддерживать нужны танцы, версионирования нормального нет. А проблема не уйдёт, внутри хранимок тоже надо организовывать синхронизацию потоков.
С селекторами в redux получается точно такой же непереиспользуемый код, но вместо простой обёртки (если она действительно нужна), приходится подключать компонент к стору и писать селекторы.
Конечно каждый выбирает что ему больше по душе, мне оказалось больше по душе написать обёртку.
P.S. В mobx есть ещё одна плюшка — отсутствие необходимости нормализовывать стейт, вместо этого можно хранить сложные графы объектов предметной области и не париться.
Блин, вам не нужно оборачивать компоненты чтобы угождать mobx. Берите и используйте как привыкли, mobx всё это нормально скушает. Как только у вас появится желание оптимизировать выделяете кусок рендера в отдельный компонент и всё, без селекторов, shouldComponentUpdate и прочего.
То есть по вашему, необходимость передавать
<TodoItem todo={todo}>— это слишком "ненормально"? Вкусовщина чистой воды, мне вот больше нравится передавать сущности отдельным атрибутом, а не spread-оператором.Обратите внимание, что все ваши примеры работают из коробки, ни с чем бороться не приходится, динамический текст в кнопке тоже работает. Но для получения большей производительности надо бить приложение на мелкие компоненты, и соблюдать некоторые правила.
В случае с redux для достижения той же производительности придётся писать дополнительный код, а не реорганизовывать существующий.
Именно так и происходит при использовании redux. С mobx — нет. Потому что в нём не меняется store. В нём меняются объекты внтури него. Например при изменении поля
nameу объекта классаTodoобновится только один конкретныйTodoItem, который его отображает. Все соседние не будут изменены, а также сам список тоже. Это будет верно даже если в TodoItem не будет передан (в явном или неявном виде) store. Как раз за счёт реактивности. Должно быть только одно — компонент его отображающий должен быть@observerи всё.Если вам интересно, я могу как нибудь сделать форк mobx-todomvc и переписать его убрав передачу
storeво все дочерние компоненты, вы увидите что это ничего не изменит.Проброска в компоненты store — всего лишь один из вариантов написания приложения. Вы можете пробрасывать либо через контексты (как и делает react-redux в его функции connect), либо вы можете оставить store только в рутовом компоненте, но пробросить во внутренние компоненты чистые данные/коллбеки и всё будет работать.
Сложнее. Почитайте https://habrahabr.ru/post/304340/
React не проверяет propTypes при сравнении vdom.
Нет не равносилен, потому что shouldComponentUpdate блочит ререндер всего поддерева компонента, а mobx/react позволяет доставлять точечно обновления куда следует.
https://twitter.com/mweststrate/status/718444275239882753 — тут можно посмотреть сравнение туду-листа написанного с использованием redux vs mobx. С тем же mobx приходится писать сильно меньше обслуживающего кода, и получаем из коробки производительность.
https://habrahabr.ru/post/304340/ — здесь отличный пример того, о чём я говорю. Посмотрите в статье бонусный совет в самом конце.
Идея то идеей, однако в большом развесистом приложении со сложными взаимосвязями рано или поздно всё придёт к тому, что на каждый чих будет вызываться render каждого компонента. А их много. Причём в резальтате ререндера не происходит обновления DOM — то есть ререндер был вхолостую. mobx/cellx позволяют эту порблему решить точечно дёргая рендер только тех компонентов, которые действительно надо обновить.
Да, в redux того же можно достичь, но с большим объёмом ручной работы, с использованием всяких reselect, с хитрыми shouldComponentUpdate и так далее.
Но ведь и для express можно написать обработчик роута в async/await стиле:
Конечно можно — можно на каждый чих целиком рендерить страницу и заменять её. Реакт в общем то делает тоже самое, за одним искчлюением — он не заменяет дом-дерево каждый раз на новое, он его точечно обновляет, за счёт чего в общем то и достигается скорость.
Кстати очень хотелось бы послушать аргументы, почему именно такой стиль является "извращённым".
Например мы используем реакт не за его оптимизации над DOM. А из-за того, что на нём очень просто описывать мутации состояния интерфейса. Если быть точным — их не надо описывать вообще, просто описываешь один раз как рендерится стейт и меняешь его в процессе жизни приложения. На jQuery все такие мутации надо описывать вручную — типа а вот сейчас надо добавить строку в таблицу, для этого надо взять tr, напихать в него td, и так далее, и сделать добавление в конец tbody. В реакте этого делать не нужно.
Спасибо за опыт с loopback
Chain механизм вполне работает и со стандартными
&&операторами, ваш пример можно записать так:assert(typeof req.body === "object" && "error text" === req.body.error)Ну или два assert написать, будет ещё читаемее. Писать это несравненно легче.
Я действительно пробовал писать проверки в стиле should/expect, очень бесило то, что постоянно приходится лазить в документацию на первых этапах.
Описание условий формальным языком работало бы, если весь тест им описывался. А по факту — формальным языком описываются только ассерты, а код теста всё равно на обычном ЯП (в нашем случае javascript). В итоге тестировщику проще нучиться js, раз уж его всё равно надо знать.
Ну и использование bdd-style проверок не делает тест автоматически проверяющим поведение. Я видел кучу юнит тестов, в которых проверки написаны в стиле expect/should.
В итоге — не переубедили :) Я всё ещё считаю что expect/should синтаксис — оверинжениринг из разряда "потому что можем" с сомнительным профитом
Объясните мне, пожалуйста, неужели приятно использовать chai?
Вот эта вот вся магия типа
req.should.have.status(200), её же писать умучаешься!Для себя решил что всегда в качестве assert-библиотеки буду использовать power-assert:
assert(req.status === 200)— всё чётко и понятно, писать проще, читать легче, а power-assert даёт понятное описание ошибки.Может быть я сильно заблуждаюсь а
chaiявляется верхом инженерной мысли?Нет, внутри тот же хромиум, а не свой движок со своими багами.