Интересно, додумается?

Так это не в эффекторе косяк) А в том, что данные прокидываются из компонента списка в компоненты айтемов и при любом изменении апдейтят список

реакт сам по себе сложная либа (целиком) но добавляя ещё больше сложнейших либ, усложняется работа над кодом самого приложения. ты описал кейс, когда косяк в юзер реализации, но это большинство проблем со сложнейшими либами: они увеличивают область знаний которые нужно освоить, чтобы просто писать приложение хотя мне хочется просто view = ƒ(state) и mobx этого мне не дает

реакт сам по себе сложная либа (целиком) но добавляя ещё больше сложнейших либ, усложняется работа над кодом самого приложения. ты описал кейс, когда косяк в юзер реализации, но это большинство проблем со сложнейшими либами: они увеличивают область знаний которые нужно освоить, чтобы просто писать приложение хотя мне хочется просто view = ƒ(state) и mobx этого мне не дает

Вопрос не в сложности либы, а в сложности абстракции, которую она предоставляет.

Вопрос не в сложности либы, а в сложности абстракции, которую она предоставляет.

и в сложности либы в том числе, чем больше кода, тем сложнее изучать api и больше особенностей использования. следовательно сложнее писать код в соответствии с идеологией

реакт сам по себе сложная либа (целиком) но добавляя ещё больше сложнейших либ, усложняется работа над кодом самого приложения. ты описал кейс, когда косяк в юзер реализации, но это большинство проблем со сложнейшими либами: они увеличивают область знаний которые нужно освоить, чтобы просто писать приложение хотя мне хочется просто view = ƒ(state) и mobx этого мне не дает

Проблема, описанная мной, была вообще вне контекста каких-либо библиотек, кроме реакта. Чего ты мне-то это пишешь)

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

и в сложности либы в том числе, чем больше кода, тем сложнее изучать api и больше особенностей использования. следовательно сложнее писать код в соответствии с идеологией

Очень спорно. Посмотрим на задолбавший всех эффектор. У него очень тонкая и понятная абстракция. Остальной код - это оптимизация работы кишков.

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

А я хочу максимально простой компонент Который выполняет только одну вещь - рендерит кнопки И не тянет за собой бизнес-логику

Очень спорно. Посмотрим на задолбавший всех эффектор. У него очень тонкая и понятная абстракция. Остальной код - это оптимизация работы кишков.

я же не великий творец, что изрекаю только неоспоримые истины. но у того же эффектора SSR делает через жопу и замыкания

я же не великий творец, что изрекаю только неоспоримые истины. но у того же эффектора SSR делает через жопу и замыкания

У эффектора жопа с SSR только по одной фундаментальной причине) Нет локальности.

реакт сам по себе сложная либа (целиком) но добавляя ещё больше сложнейших либ, усложняется работа над кодом самого приложения. ты описал кейс, когда косяк в юзер реализации, но это большинство проблем со сложнейшими либами: они увеличивают область знаний которые нужно освоить, чтобы просто писать приложение хотя мне хочется просто view = ƒ(state) и mobx этого мне не дает

как раз наборот - с mobx можно использовать реакт просто как view = f(state) добавив всего лишь врапперы над компонентами и над полями больше не меняя вообще код проекта. Вот даже статья есть на эту тему https://habr.com/post/416361

А я хочу максимально простой компонент Который выполняет только одну вещь - рендерит кнопки И не тянет за собой бизнес-логику

вот в итоге, всем нужен слой бизнес-логики который зависит только от API стора умеет принимать события и отправлять данные в сторе чтобы можно было переписывать способ хранения данных не ломая логику а также переписывать логику не ломая фронт

вот в итоге, всем нужен слой бизнес-логики который зависит только от API стора умеет принимать события и отправлять данные в сторе чтобы можно было переписывать способ хранения данных не ломая логику а также переписывать логику не ломая фронт

E f f e c t o r

как раз наборот - с mobx можно использовать реакт просто как view = f(state) добавив всего лишь врапперы над компонентами и над полями больше не меняя вообще код проекта. Вот даже статья есть на эту тему https://habr.com/post/416361

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

E f f e c t o r

он реализует стор

Нет, он реализует и то, и то)

я бы рванулся проверять все подводные камни, если бы не SSR

Ты можешь менять способ хранения данных и не менять бизнес-логику) Просто напиши новый .on() для переделанного стора и все

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

ну практически не меняя код проекта, я имел ввиду что не нужно вообще менять архитектуру или код работы с состоянием

const name = createStore('') const changeName = createEvent('Change name') Зависит друг от друга?

Если я переименую name, у меня отвалится жопа?

Ты можешь менять способ хранения данных и не менять бизнес-логику) Просто напиши новый .on() для переделанного стора и все

ещё одна штука которая меня клинит — связка производится достаточно неявно то есть просто ниже пишешь store .on(event, handler) и всё

я бы рванулся проверять все подводные камни, если бы не SSR

Вопрос к тебе. Ты готов взять стор, если тебе понадобится немного патчить реакт?

А что ты еще хочешь от изменения стейта?

Вопрос к тебе. Ты готов взять стор, если тебе понадобится немного патчить реакт?

нет

нет

Печаль.

Бедный лис, никому не нужен патченный реакт

Вопрос к тебе. Ты готов взять стор, если тебе понадобится немного патчить реакт?

?

А что ты еще хочешь от изменения стейта?

я хочу полностью отдельно. const store = createStore() const login = createLogic(store) render(<App store={store} />, root)

Бедный лис, никому не нужен патченный реакт

Надо ещё придумать как нормалньо пропатчить.У меня косяк с stateful компонентами сейчас.

Вопрос к тебе. Ты готов взять стор, если тебе понадобится немного патчить реакт?

Ты просто не пиши это напрямую, а напиши "All you need is to call init()"

я хочу полностью отдельно. const store = createStore() const login = createLogic(store) render(<App store={store} />, root)

Здесь зависимость от стора)

Здесь зависимость от стора)

я выше это написал

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

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

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

Ты просто не пиши это напрямую, а напиши "All you need is to call init()"

Мне надо пропатчить render у классов и React.CreateElement

Мне надо пропатчить render у классов и React.CreateElement

init(React)

Можно же не говорить, что ты там такое интересное делаешь, правда? =))

я хочу полностью отдельно. const store = createStore() const login = createLogic(store) render(<App store={store} />, root)

я также хочу подключать и отключать куски логики в рантайме

Можно же не говорить, что ты там такое интересное делаешь, правда? =))

Плохая идея.

Можно же не говорить, что ты там такое интересное делаешь, правда? =))

Я предпочитаю отдельный пакет, который просто алиасом подключаешь и всё работает.

Слушайте, как можно задетектить stateful компонент реакта?

Я предпочитаю отдельный пакет, который просто алиасом подключаешь и всё работает.

делай форк реакта и поддерживай его

делай форк реакта и поддерживай его

Вот это ещё большее говно.

я хочу полностью отдельно. const store = createStore() const login = createLogic(store) render(<App store={store} />, root)

const SaveButton = <Button onClick={() => save()}>Save</Button> const save = createEvent('Save') const store = createStore('a') .on(save, () => 'saved') При изменении стора я поменяю только .on(), который лежит ровно в этом же месте В твоем случае мне придется менять и стор, и logic - 2 места

Я лучше объясню что я делаю и попытаюсь влить в апстрим реакта, чем делать полный форк.

Вот это ещё большее говно.

юзай hyperapp :D

const SaveButton = <Button onClick={() => save()}>Save</Button> const save = createEvent('Save') const store = createStore('a') .on(save, () => 'saved') При изменении стора я поменяю только .on(), который лежит ровно в этом же месте В твоем случае мне придется менять и стор, и logic - 2 места

не придется

не придется

в смысле не придется, лол

Вот мне, сука, очень не хватает того, что реакт сжирает key и не пробрасывает его в компонент.

Тупо компоненты на уровне стора различить нельзя из-за этого.

Вот мне, сука, очень не хватает того, что реакт сжирает key и не пробрасывает его в компонент.

Сделай DO_NOT_CHANGE_IT_OR_YOU_WILL_BE_FIRED, как это обычно делают

Я понимаю зачем это сделано, но блин.

Кстати, о птичках Специально для совы есть createApi

const SaveButton = <Button onClick={() => save()}>Save</Button> const save = createEvent('Save') const store = createStore('a') .on(save, () => 'saved') При изменении стора я поменяю только .on(), который лежит ровно в этом же месте В твоем случае мне придется менять и стор, и logic - 2 места

потому что в моем случае, стор это ТОЛЬКО хранение данных и ничего больше. стор сам занимается тем как и в каком виде хранить данные ты наружу вытаскиваешь только апи для использования почти procedure call логика лишь дергает стор, чтобы получать данные или обновить через методы/экшены переписывай стор как тебе вздумается не ломая апи также и логику

const { a } = createApi(store, { a: (state, payload) => newState })

В реакте есть встроенный механизм сопоставления компонентов и их сторов. А пользоваться им писателям либ не дают.

const { a } = createApi(store, { a: (state, payload) => newState })

Говно нетипизируемое.

потому что в моем случае, стор это ТОЛЬКО хранение данных и ничего больше. стор сам занимается тем как и в каком виде хранить данные ты наружу вытаскиваешь только апи для использования почти procedure call логика лишь дергает стор, чтобы получать данные или обновить через методы/экшены переписывай стор как тебе вздумается не ломая апи также и логику

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

Я отказался от такого апи поэтому.

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

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

В реакте есть встроенный механизм сопоставления компонентов и их сторов. А пользоваться им писателям либ не дают.

rfc

Будет у меня в сторе объект, а изменю я его на строку. И че теперь

Будет у меня стор с одним объектом, а станет с другим. Более логичная ситуация. И че теперь

Будет у меня в сторе объект, а изменю я его на строку. И че теперь

ты можешь легко прокинуть ты не обращаешься к полям стора никогда

rfc

До rfc надо рабочее решение, которое показывает необходимость, предоставить. Иначе меня как ноунейм челика просто нахуй пошлют.

ERROR: S client not available

ты можешь легко прокинуть ты не обращаешься к полям стора никогда

А как апдейтить стор?

А как апдейтить стор?

методы

ПУБЛИЧНОЕ АПИ

Очень хорошо. Что будут делать методы?

И да, я против того, чтобы key попадал в пользовательский код. Это говно.

Очень хорошо. Что будут делать методы?

принимать/возвращать данные

@sergeysova Возращаясь чуть ранее. Ты уверен, что отключение методов стора - это хорошая вещь? Говной воняет.

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

@sergeysova Возращаясь чуть ранее. Ты уверен, что отключение методов стора - это хорошая вещь? Говной воняет.

“отключение методов стора” ты о чем?

То есть априори логика определяет стейт

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

где я сказал, что логика возвращает новый стейт?

принимать/возвращать данные

А что это

А что это

блядь данные != стейт логика != методы стора

Тогда опиши мне, что будет внутри createLogic и как он будет работать со стором

блядь данные != стейт логика != методы стора

А почему второе по-твоему верно?

А почему второе по-твоему верно?

потому что я хочу так

я не хочу завязывать стор и логику

я заебался от каждого серьезного изменения стора переписывать и логику и рендер

Бля. Почему человек говорит, что не хочет завязывать стор и логику, и в примере завязывает их. Помогите плиз

я заебался от каждого серьезного изменения стора переписывать и логику и рендер

А как ты будешь писать логику, которая не зависит от стора?

С чем логика то работать будет?

А как ты будешь писать логику, которая не зависит от стора?

Вот я этого ответа и хочу добиться. Но ответа нет

Тогда опиши мне, что будет внутри createLogic и как он будет работать со стором

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

- Логика не работает со стейтом - А с чем она работает? - С данными (данные != стейт) Заебись. И тут мне нужно сделать инкремент счетчика в сторе

- Логика не работает со стейтом - А с чем она работает? - С данными (данные != стейт) Заебись. И тут мне нужно сделать инкремент счетчика в сторе

псевдокод: store.incrementCounter()

псевдокод: store.incrementCounter()

Ну нихуя себе, логика в сторе

Ну нихуя себе, логика в сторе

нет там логики

А ЧТО ЭТО

ЭТО ОБНОВЛЕНИЕ ДАННЫХ

и нихуя болшье

это то, чем занимается симбиот

Ахуеть, которое завязано на данных из стора