Я не знаю, я чисто за идею болею

dirname удалить и все?

да, если сервер запускаешь из папки проекта

?

а вот тут в закладочке preview он тебе что показывает?

веб страничку?

есть вариант, что экспресс с роутами коряво настроен

одно дело дев окружение

ну тогда логай что выдает __dirname и добирайся до своей папки

где вебпак дев сервер

@ZeroBias effector какую версию лучше брать? мастер? 0.14? девелоп?

Девелоп, я её сегодня замержу в мастер

а вообще есть какой то роад мап по развитию либы?

там не ишью совсем

@ZeroBias effector какую версию лучше брать? мастер? 0.14? девелоп?

effector@0.16.1-beta.8 effector-react@0.16.1-beta.8

а вообще есть какой то роад мап по развитию либы?

до версии <1.0.0 нужно отладить воркфлоу для основных кейсов, написать руководства

вот из этих 4-х сущностей Domain, Event, Effect, Store

в принципе понятно все кроме домена пока

Не стесняйтесь кстати открывать issues если что-то не понятно, так гораздо проще работать над проблемами

в принципе понятно все кроме домена пока

Домен — это т.н. "фича", обозначает раздел приложения либо область знаний, короче просто группировка по смыслу

ага понятно

сейчас схожу за пивОм и начну колбасить с эффектором

постоянно нужны новые идеи, а то работа превращается в какую то рутину :))

effector@0.16.1-beta.8 effector-react@0.16.1-beta.8

Отдельно обращаю внимание что здесь два пакета)

Идея такая примерно import {createStoreComponent} from 'effector-react' import {createStore} from 'effector' const fooStore = createStore('foo') const Foo = createStoreComponent(fooStore) const App = () => <Foo> {foo => <div>{foo}</div>} </Foo>

То есть это как Consumer в новом контексте

а ну это типа Provider из react-redux

@ZeroBias я так понимаю ничто не мешает использовать две парадигмы совместно тут типа редакс и эффектор?

т.е. где хочешь оборачиваешь в коннект редакса

где хочешь юзаешь ваш подход

Ну да

вот эта связка часто вижу в примерах

.reset(resetForm)

const resetForm = createEvent('reset form')

Эвент, который сбросит состояние стора в дефолтное значение

просто обнуление стейта?

ага понял

т.е. если сработает resetForm где-то, то соответствующий стейт обнулится

Ага

Первая мысль — можно же сделать .on(resetForm, () => initialState) но на практике гораздо приятнее не иметь переменной initialState вообще, ввиду чего появляется потребность в таком хелпере

кстати каверзный вопрос

что произойдет в случае

.on(changeText, (state, text) => ({ ...state, text, })) .on(changeText, (state, text) => ({ ...state, text, })) .on(changeText, (state, text) => ({ ...state, text, }))

т.е. дублирование

по ошибке, опечатке и т.д.

вот в случае [changeText]: ... там будет все понятно даже на уровне IDE

она скажет что ключи задублированы

мне просто с таким паттерном случалось столкнуться в redux-loop

в проекте где парни на это богу молились

ну и огребали соответственно :)))

т.е. дублирование

А какого поведения бы хотелось?

по хорошему рантайм должен выбросить предупреждение/исключение

все зависит от того билдишьты это один раз

или прогоняешь каждый раз по цепочке

Сейчас там отработают оба редьюсера (так как либа по максимуму прощающая косяки), надо это конечно тоже покрыть тестами

А, во

Новый редьюсер должен подменить предыдущий без эксепшнов, но с варнингом для разработчика

ну типа того

Сейчас например каждый новый вызов .use подменяет предыдущий вариант, так что это было бы консистентно

т.е. в любом случае предупрежден значит вооружен

Ага

.on(changeText, (state, text) => ({ ...state, text, })) .on(changeText, (state, text) => ({ ...state, text, })) .on(changeText, (state, text) => ({ ...state, text, }))

Хинт — ты можешь вешать .on на text store, в таком случае объединённый стор будет обновляться сам, а запись будет существенно проще

const text = createStore('') const foo = createStoreObject({text}) text.on(changeText, (state, str) => str)

у меня есть своя наработка для редакса с очередями запросов их прерыванием и всем набором, при чем там без разницы через что приходит ответ через веб сокеты, евент соурс или рест апи, т.е. ты можешь в любой комбинации делать запросы и принимать ответы, все это однозначно связывается между собой + отрабатывают канцелы и таймауты но есть нюанс

слишком слжная инициализация приложения и надо все это перерабатывать конечно

там асинхронные импорты одни ждут других и т.д.

там асинхронные импорты одни ждут других и т.д.

У меня такое тоже было

я хочу все упростить для себя

убрать на фиг всю магию из новых проектов

Я с пурскрипта avar портировал, лолл. Но поюзав, я отказался от этого, слишком сложная имплементация

старые работаеют норм как часики

но в новые затаскивать все это не хочу

ну вот представь у меня там экшины где создаются есть декоратор

когда он вызывается он должен зарегать все и создать класс новый

который должен знать что такое стор редакса

которого пока нет

ну и дальше начинаются танцы с бубном

куча промисов

которого пока нет

Именно эту проблему я и решал)

ждем стораджа

и погнали

ну понятно

там асинхронные импорты одни ждут других и т.д.

https://github.com/zerobias/effector/blob/ffa103d32aad2db9260e48a87545eb48087c3b78/packages/avar/src/__test__/index.test.js

Оочень крутая штука, но объективно слишком сложно, пришлось удалить её

Там упорядоченные reads, ты физически не можешь прочитать значение раньше чем оно появится

Решил что лучше заимплеменчу поверх базовых функций эффектора

ну вот как бы в целях познания мира это все прикольно

но со временем хочется какой-то простоты

Угу

и прозрачности

В моём случае скорее предсказуемости

чтобы все всегда держать под контролем

await внутри логики в данном случае означает отсутствие контроля, для меня это было прям огромной проблемой, когда я имел только эпики

Поэтому эффектор без блокирующих операций)

ну я сейчас где руки дотягиваются убираю эвейты

раньше пихал туда сюда обратно

наверное из-за недопонимания

вон в апи которое выше кидал