Как стать автором
Обновить
13
0
Андрей Маслов @amas1ov

Software Engineer

Отправить сообщение

В последующих статьях уделю большее внимание этой проблеме, спасибо!

Статьи носят ознакомительный характер, в данной - разбираются вещи, которые явно в повседневной разработке не задействованы, поэтому если при разработке вы столкнетесь с проблемой, то вряд ли, не зная о существовании infer, вы оперативно сможете решите свою проблему. Я так это вижу, но реальные примеры из проектов, которые решают реальные проблемы, стоит добавить при разборе инструмента абсолютно точно)

Человек, удалив зависимости, в виде материал ui и других, почистив код и приведя его к низкому уровню, пытается выставить mol (оперируя фактами кол-ва строк кода и объема зивисимостей), зачем - вопрос. Хотя статья - туториал, и никаких сравнений здесь не должно быть)

Вместо отчетливо видимой

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

без существенной экономии кода. И это в самом базовом варианте.

В том то и дело, что в базом варианте экономии и не видно (для меня это не только про экономие, но и про удобство - это из рязряда нужно брать и пробовать), чем больше компонент, чем больше у него состояний, тем больше наша "экономия", + в статье писал про обертку

export const statusesList = ({ effect, source }: Store<ListState>) => {
  return combine(status({effect}), source, (effectStatus, list) =>
    effectStatus === 'done'
      ? Object.values(list).length
        ? 'done'
        : 'empty'
      : effectStatus,
  );
}
....

export const $someStoreStatus = statusesList({
  effect: someEffect,
  source: $someStore,
});

Здесь мы можем обработать базовые исходы все, и теперь, когда в "Было" мы будем каждый компонент обмусоливать, в "Стало" вызовем list и передадим базовые кейсы, вызвав statusesList. (к слову, подобное можно реализовать в любом инструменте, дело в поддержке всего этого написанного)



Отлично , спасибо!

Все от сложности проекта зависит, верно подметили.

Вопрос в том, что следующему разработчику надо будет теже полгода + время на вкуривание уже написанного кода, и только потом дело пойдёт.

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

Всё-таки выборка для оценки должна быть побольше, например три проекта на мобх, и три проекта на эффекторе. При чём не так, что начинал с нуля, а потом уволился (потому что говорят что надо "развиваться" и прыгать с места на место). А наоборот, чтоб пришёл на проекты уже которые в возрасте.

Соглашусь.
У меня с МобХ первый проект сейчас, поэтому никакой конкретики не приводил, плевки в сторону других решений не делал. Вкатился быстро, да так же как и можно вкатиться в проект на эффекторе (если рядом тебя за ухо поднатаскают), единственное отличие - у эффектора инструментарий будет пошире (и в ssr и в байндинг пропсов (никаких тебе вызовов юзстора в компонентах), ну и тд, следующую статью по инструменталу как раз готовлю), в этом и сложность для многих.

Спасибо за комментарий )

Вообще не понимаю о чем речь, просто набор слов. Уверен что вы что-то имели ввиду, но тут опять же без доли сомнения проблема только в ручках тех, кто пишет код.

Ввел в заблуждение знаком препинания, прокси и остальную часть предложения нужно расцепить.
Вообще посыл ответа был таков, что нам приходится трястись над данными, например, обмазываться toJS
Я с МобХ работаю не так давно, и не могу давать какое-то "экспертное" мнение, вы в этом явно лучше.

Очень смешно когда в качестве "аргумента" ставят десяток килобайт в бандле, который капля в море в реальных проектах. Ещё больше смешно, когда не называют конкретные цифры, а говорят в 2.5 раза

Ваша проблема решается минутой гугления, не из головы взял

С MobX открываешь документацию, потом 3.5 примера и все

Вы правы, если цель - развернуть приложение, создать стор и крутануть счетчик. Речь шла про понимание самого подхода

А $ в названиях переменных так это вообще вишенка на торте

Это рекомендации, как и название интерфейсов или представлений компонент и тд.

Напомню, что в начале статьи написал следующее (Не было цели сравнивать что-то, цель - ознакомительный характер, а ваши комментарии начинают нести придирчивый характер):

Часть №1 будет нести ознакомительный характер c инструментом, чтобы вы могли понять, нужен ли вам Effector или нет...

Больше никакого бойлерплейт-кода.

Немного недопонимание вышло, возможно.
Речь шла о бойлерплейт коде именно стейт-менеджера, например:

Redux

//actions.ts - Определить экшен

const someAction = function (props) {
  return {
    type: "SOME",
    props
  }
};

//reducer.ts - обработать экшен и изменить стор

const reducer = function(state, action) {
  switch (action.type) {
    case "SOME":
        return ...
  }
  return state;
}

//Component.tsx

const Component = () => {
  const dispatch = useDispatch()

  const handleSome = () => {dispatch(someAction())}

  return (...)
}

vs Effector

//init.ts

const someAction = createEvent()

const $someStore = createStore()
                      .on(someAction, (state) => state)

const Component = () => {

  const handleSome = () => {someAction}

  return (...)
}

И это мы в редасе еще стор сам не создавали, initialState не описывали и тд )
Думаю, вы меня поняли.

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

Спасибо за комментарий.

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

Хоть на грамм может что-то сопоставить MobX'у?

У MobX (сейчас как раз на проекте используем) есть свои проблемы (как и у Effector, не пытаюсь боготворить). Например, неявные подписки на наблюдаемые изменения, из-за Proxy приходится писать постоянно модели данных (иначе консоль у тебя засыпается предупреждениями, и это не говоря про реактивный контекст). Store становится сборной солянкой из наблюдаемых, вычисляемых значений, экшенов и всего остального, если фича начинает разрастаться.

В эффекторе же у вас есть только события, которые способны изменять стор.
Effector будет полегче того же МобХ почти в 2,5 раза (говорю про связку с реактом).

вырви глаз "код" и "подход"

Подход, действительно, необычный. Я упоминал в статье, что первые полгода не мог привыкнуть. Про "вырви глаз код", здесь каждому свое, по мне так код effector один из наиболее приятных.

Информация

В рейтинге
Не участвует
Откуда
Томск, Томская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Frontend Developer
Lead
TypeScript
React