Pull to refresh
16
Андрей Маслов@amas1ov

Software Engineer

22
Subscribers
Send message

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

Статьи носят ознакомительный характер, в данной - разбираются вещи, которые явно в повседневной разработке не задействованы, поэтому если при разработке вы столкнетесь с проблемой, то вряд ли, не зная о существовании 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 один из наиболее приятных.

Information

Rating
Does not participate
Location
Томск, Томская обл., Россия
Date of birth
Registered
Activity

Specialization

Фронтенд разработчик
Ведущий
TypeScript
React