Эффектор же вроде решает проблему локального стейта? Ну типа стейт собирается не снизу вверх, а наоборот?

может просто использовать разные функции для разных задач?

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

а ивент это просто жсон обьект

Эффектор же вроде решает проблему локального стейта? Ну типа стейт собирается не снизу вверх, а наоборот?

в текущей реализации куча магии, нет провайдеров и все за этим истекающее

а ивент это просто жсон обьект

и сломал бы понимание кода

каких провайдеров?

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

ивент ничего не возвращает

завязываешь на тот ивент который ты получил *

завязываешь на тот ивент который ты получил *

откуда

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

какого-то

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

не надо фанатеть от удаления связей код превратится в ад

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

какой ещё пул ивентов?

чувак, ты что там усложняешь так. это фронтенд, ты не mtproto реализуешь

ты хочешь чтобы поток исполнения стал максимально неочевиден?

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

каких провайдеров?

<Provider store={store}>

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

<Provider store={store}>

есть

да завезли

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

так а какой в этом смысл?

const FormStore = createStoreConsumer(form) const Form = () => ( <FormStore> {form => ( <form onSubmit={resetForm}> <input type="text" onChange={e => changeText(e.currentTarget.value)} /> <button onClick={resetForm}>reset</button> </form> )} </FormStore> )

так а какой в этом смысл?

максимальная связность и минимальная связанность

залог разширяемой архитектуры

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

> “выглядит будто связанное, но на деле не связанно” так это же работать не будет

const FormStore = createStoreConsumer(form) const Form = () => ( <FormStore> {form => ( <form onSubmit={resetForm}> <input type="text" onChange={e => changeText(e.currentTarget.value)} /> <button onClick={resetForm}>reset</button> </form> )} </FormStore> )

@zerobias чет пример сломанный

максимальная связность и минимальная связанность

ты фанатеешь

это не работает

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

@zerobias чет пример сломанный

Я не тестил)) Но ща скоро будет пример ?

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

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

лапша это тупо сильносвязанный код

а я наоборот стемлюсь это минимизировать

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

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

не надо фанатеть

всего должно быть в меру

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

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

а я наоборот стемлюсь это минимизировать

Может я сейчас скажу херню, но @conneсt(selector, actions) даёт наиболее читаемый код

Саговское ожидание — это то, как делать тупо не нужно

Акторы принципиально работают без блокировок

Акторы принципиально работают без блокировок

но ожидание экшена тоже есть?

Нет

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

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

Принципиально без блокировок значит что экшны тоже не ждёт))

а в чем профит этого подхода ?

Посоветуйте аплоадер годный ? Чисто чтоб апи было, без представления

Посоветуйте аплоадер годный ? Чисто чтоб апи было, без представления

<input type="file" />

<input type="file" />

Спасибо !

А с блекджеком?

А с блекджеком?

<input type="file" multiple />

в общем вопрос остается открытым для меня, как организовать некий файл роутер для апи ссылок? Или пакет какой нибудь посоветуйте удобный если знаете плиз. Вот например у меня есть просто статический линк который просит сервак вернуть список категорий, и линк в котором передается параметр к примеру author/2 или вообще линк для datatable где могут передаваться всякие сортировки и фильтры. Или вообще не морочить голову и оставить эти ссылки разбросанные по коду?

в текущей реализации куча магии, нет провайдеров и все за этим истекающее

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

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

вроде слова понятные но не понимаю ((((

Так што попрошу без поклёпа тут))

ааа

синхронный?

Да

Более того, он статический

но ты же собираешь все свои кусочки в один большой?

Это называется граф зависимостей

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

?

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

ORLY?

?

ERROR: S client not available

?

?

Хааха

а кодом как выглядит?

а куда сайдеффекты и асинхронщину?

еффекты есть

а куда сайдеффекты и асинхронщину?

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

В случае простой асинхронной функции (я подразумеваю, что в эффект оборачиваетс что-нибудь типа запроса в банк) достаточно .watch

нужна дока с примерами и пояснениями

Всем нужна, но у меня в сутках не так много времени)

Кажись тебе пора нанять помощника

если бы я юзал еффектор, то я бы написал бы доку

но вот меня как-то не убедило еще)

Всем нужна, но у меня в сутках не так много времени)

ты слишком много спишь

Я уже спал на этой неделе

а за месяц сколько раз?

Раз на раз не приходится

Раз на раз не приходится

у тебя помимо одного ишью в гх есть еще что-то? Пора в опен сорс начинать контрибьютить

о

тележка

Не могу правда сказать, что горжусь текущей имплементацией))

главное сам звездочку не поставил)

Нус, завтра пойду разбираться

А то на работе делать особо нехер

Первая версия эффектора https://github.com/zerobias/telegram-mtproto/tree/de7a54941c4965380258db1d9ca2a14de3bc6cbe/packages/telegram-mtproto/src/util/action

ребята, а как мне вызвать функцию только когда определенный див отрендерился ВПЕРВЫЕ

componentDidMount

componentDidMount

Если он про определенный див во всем скоупе, созданном в "одном файле", то нет, не так

Если он про определенный див во всем скоупе, созданном в "одном файле", то нет, не так

Тогда да

Не так

@Wrouds http://uxmovement.com/forms/the-best-place-for-error-messages-on-forms/

Нормас