Можно пример? Я, видимо, недостаточно глубоко копал MobX, мне не очевидно, как такой подход использовать.
Данные-то откуда? Из формы? Ну вот и складывайте где-то там, где у вас обработчики событий формы.
Из формы или ещё откуда-нибудь. В вашем примере мы присваиваем значение переменной. Эту переменную надо где-то хранить, чтобы потом использовать в форме. Надо создавать класс для компонента, чтобы хранить this.model, или функциональный компонент. Тоже ручная работа.
Но это всё ерунда, а вот как заставить компонент перерисовываться на изменениях модели? https://mobx.js.org/refguide/observable.html ни слова об этом не говорит, зато перечисляет аж 5 правил конвертации значений, которые нужно знать. И исключения для MobX версии 4, о которых тоже надо знать.
Зачем? Чтобы сделать форму с тремя полями?
Эм. Взять этот обсервабл и прочитать, что в нём?
Для этого надо сперва понять, что он изменился. См. предыдущий пункт.
Где же? Примеры из документации mobx очень часто написаны без декораторов.
Я не видел таких примеров для React + MobX. В документации MobX есть много примеров использования MobX в вакууме, но мне это не интересно. Я по работе использую React, мне нужно, чтобы компоненты отрисовывались по изменению состояния.
Примеров с React без использования классовых компонентов я не нашёл. Плохо искал?
Спасибо за ссылку, я в MobX копал вполне глубоко. На мой взгляд, именно работа с классами является неестественным усложнением в большей части случаев.
Ну честно, вам когда форму с полями нужно сделать, зачем для этого нужно создавать класс, поля, методы для работы с ними, да ещё и обмазывать эти методы магией @observable? В Statium всё гораздо проще: вот модель (API), вот поля с данными (initialState), вот список, какие значения куда скормить (Bind). И всё.
А если в форме нужно показывать значение из вышестоящего состояния? Имя юзера, например, или поле из родительского компонента. В Statium банальнейше, в MobX больно (ручками).
Вы посмотрите пристальнее, вдруг понравится. От ненависти до любви один шаг. :)
Это бизнес (или, вернее, менеджеры), который всё время «хочет странного».
С точки зрения этого бизнеса (или, вернее, менеджеров), вы тоже всё время хотите чего-то странного. Зарплаты, например.
Вот просто забить большой болт и всё.
Я хочу вдаваться в подробности на тему, почему "забить большой болт и всё" нельзя. Это отдельная большая тема.
Я вам о другом говорю: забить большой болт не работает. Можно забивать сколько угодно, это не поможет. Никак. Потому что у 95% пользователей всё равно будут разные браузеры, разные платформы, и разные устройства. От мощных десктопов до туповатеньких Chromebook, от последних iPhone до дешёвых китайских клонов какой-нибудь младшей модели Samsung Smartwatch. Какие критерии вы предлагаете использовать для исключения тех и этих, чтобы ваша жизнь была попроще? Назад в будущее, к This site is best viewed in IE6?
По вашим словам мне очевидно, что вы просто не владеете предметной областью. Так и должно быть, front end не ваша специализация. Это моя специализация, и я отлично знаю из опыта и толстой мозоли на лбу, почему нельзя "просто взять и сделать" сайт, чтобы всё работало и все были довольны.
Я стараюсь не вспоминать о битвах с нативным скроллингом документа, который есть сущее, адское зло — а виртуальный скроллинг это тоже сущее, адское зло. У меня в печёнках сидят поля ввода в HTML, обработка фокуса, маски и валидирование значений. Меня тошнит от touch events, от распознавания жестов по таймауту и ловли утёкших таймеров (ручками, всё ручками!). Я молча посылаю пламенные лучи ненависти и поноса в сторону HP, Lenovo и прочих умников, выпускающих лаптопы с тачскринами, которые никак особенно не определяются в браузере и потом к чертям ломают всю обработку событий, потому что смешать pointer events и touch events это — а чо, у нас в Windows работало? Я плачу кровавыми слезами каждый раз, когда мне нужно лезть в caniuse.com и подтверждать, какие фичи из CSS3 работают в последнем мобильном Сафари, а какие нет. И т.д. и т.п., конца и края этому нет (и не будет).
Можно всё это игнорировать, для личных проектов сойдёт — кому они нужны, кроме вас. А для коммерческих проектов не сойдёт, и игнорировать уже не получится. Добро пожаловать в добрый, светлый мир front end. :)
Это всё же не совсем то, о чём я говорил. Прокси-сервисы и middleware тоже ломаются иногда, настройки слетают, и всё такое.
Но в back end практически не бывает так, чтобы без каких-либо изменений в вашем коде/настройках/Dockerfile/K8s/whatever, вдруг внезапно всё сломалось и перестало работать.
А на frond end — легко. Домен третьесторонней интеграции кто-то добавил в чёрный список, и привет. Узнать об этом, кроме как из разъярённых воплей обиженных клиентов, вообще никак нельзя. Это не хаос?
Вы так говорите, как будто я front end не делал. Делал. И не раз. Нет там никакого хаоса.
При всём уважении, ваши слова только подтверждают разницу между "делал, и не раз" и "занимаюсь этим постоянно". Вы этот хаос или намеренно игнорировали, или просто не успели заметить.
Если даже не вдаваться в поэзию, то самый поверхностный анализ ситуации позволяет увидеть, что благодаря наличию:
Различных браузеров, разных версий
Различных платформ и устройств
Абсолютно неконтролируемых сетевых условий
Абсолютно неконтролируемых условий среды в браузере
… и т.д., и т.п., поверхность потенциально проблемной области в front end разработке в разы больше, чем в back end. Если не на порядки.
Просто для примера, из свежего: у вас в практике часто бывало, чтобы на серверной стороне в код без спросу внедрился случайный третьесторонний модуль и начал блокировать вызовы к каким-либо микросервисам? И его не убрать никак. А у нас это норма жизни, ad blockers или какие-нибудь расширения в браузере могут в любой момент поломать что угодно. И объясняй потом бизнесу, почему их интеграция с каким-нибудь Appcues не работает и как её починить (а починить нетривиально).
И таких ситуаций, факторов, ошибок, особенностей, да просто багов — сотни, тысячи их. И каждый день что-то новое.
Да, пардон, я не посмотрел исходники до конца, и не увидел, что оно всё заканчивается контекстами.
Фух, спасибо, отлегло. А то я уже в исходники полез, вдруг что-то где-то течёт… :)
Я не буду спорить за идеологию реакта (хотя бы потому, что не считаю её в принципе хорошей),
Ага, вот тут уже понятнее. Если честно, я с вами вполне согласен — React это не самое лучшее решение, как идеологически, так и практически. Но по разным совершенно не техническим причинам, React есть реальность, данная нам в ощущениях. Можно это оспаривать сколько угодно, но если вы сравните количество вакансий на React со всем остальным, то...
В общем, в заголовке репозитория так и написано: Statium это прагматичный подход к управлению состоянием в React. :)
но «нет» в первую очередь потому, что состояние — это не компонент, и нет ни малейшей необходимости делать его таковым.
Состояние это не компонент, состояние это просто набор данных. Компонентом является хранилище состояния, фактически это просто API для доступа к объекту с данными.
Необходимо ли было делать это API в виде компонента? Нет конечно, есть и другие варианты; у этого же подхода есть как минимум одно большое преимущество: лёгкость использования в функциональных/презентационных компонентах. Гораздо проще и быстрее написать вот такой код:
… чем функцию, которая что-то с чем-то соединяет, или @observable магию, которая рассыпается без поддержки декораторов, etc.
так-то я понимаю, что вам для решения проблем реакта хотелось воспользоваться его же кодом, который с определенного угла зрения вполне себе нормально работает.
Да, вы правы. В какой-то момент мне надоело бодаться с ветряными мельницами. If you cannot beat them, join them и всё такое.
Тем более, что если допустить, что с какой-то точки зрения React вполне себе работает, то может, и ладно? Работает себе, давайте используем существующие механизмы. В конце концов, зарплату платят за фичи. :)
Но выглядит это как нагромождение абстракций там, где вообще-то можно гораздо проще.
Вполне возможно, что оно так выглядит из-за плохого изложения материала. Над документацией мне ещё работать и работать, это факт. Потому что с моей точки зрения, абстракций в ViewModel как раз почти нет: это тупо тот же самый setState, только вынесенный в отдельный компонент.
И скорее всего это всё очень небесплатно для производительности.
Понятно, раздел с анализом производительности надо поднять наверх. :) Я его в конец README засунул, так не работает.
Вообще всё с точностью до наоборот: ViewModel работает безобразно быстро. Т.е. настолько, что я сколько ни пытался профилировать на работающих приложениях, ViewModel и сопутствующий код даже не заметно в Call Tree, надо очень глубоко копать.
А если подумать, то чему там тормозить? Собственно данные ViewModel лежат в обычном объекте, который связан по прототипной цепочке с родительскими объектами. Чтение по ключу из объекта это как раз то, что JavaScript умеет делать очень быстро. :)
Обновление состояния тоже ненамного дороже родного для React this.setState(). А поскольку ключ обновляется в модели-владельце, то рендеринг отрабатывает только для этой модели и её детей. Ну т.е. в самом худшем случае, если у вас абсолютно все ключи в одной модели в корне приложения, получаете такой как бы аналог Redux. :)
Но соль-то как раз в том, что запихивать всё состояние в одну модель просто нет надобности. В Redux так делают из-за официальной рекомендации свыше, но на мой взгляд, причина очень проста: больше одного store в Redux это очень, очень больно. Нужно вручную устанавливать и отслеживать все связи, изменения, и т.д.
А в Statium всё просто: каждая модель автоматически имеет доступ к родительским данным, и вы просто можете их использовать там, где нужно. И любимая проблема: упс, я задал ключ foo вот здесь, а он нужен ещё вон там в соседнем компоненте, решается банально переносом одного свойства в родительскую модель. И всё просто работает. :)
Спасибо за отзыв. :) Можно поинтересоваться, что именно вызвало у вас такую реакцию? Концепция хранения данных в компоненте, иерархическая связь, кривизна API, или код примера? Или всё вместе? Ну правда, интересно же. :)
Спасибо за критику, очень интересно. Можно по пунктам?
Да, давайте в компоненты еще и модель затащим.
А почему нет? Этот подход идеологически ничем не отличается от this.setState() в компонентах; практически разница только в том, что состояние делегировано в отдельный, предназначенный для этого компонент. Специализированность компонента позволяет решать проблемы доступа к данным без текущих абстракций, а то, что хранилище является компонентом, позволяет использовать все оптимизации, наработанные в React с его появления.
Внутри ViewModel используется именно setState, вполне ванильно.
Я, собственно, ничего особо против вашего проекта не имею, но вот загаживать DOM тем, чему в ней явно не место — это сильный моветон.
Подождите, какой DOM? ViewModel ничего не рендерит в DOM, это виртуальный компонент с хранилищем для данных. Или я как-то не так вас понял?
Глас вопиющего в пустыне… Людям, которые работают с простыми, очевидными, и прекрасно контролируемым условиями в back end, никогда не понять хаоса и дикого Запада front end.
Всё верно, только не как будто. Это и есть аргументация в суде против вас.
Я тоже не особо читал договоры и верил в человеческую порядочность, пока не привелось получить судебный иск на миллион долларов от бывшего партнёра и работодателя в своё честное, открытое физическое лицо, проживающее в социалистическом штате Канифольния. В процессе узнал много нового и интересного, например: если на вас подали иск и вы не подали прошение о защите, то истец признаётся правым автоматически, и получает всё, что запросил. Это закон. Процесс защиты долгий и сложный, документы должны быть подготовлены аккредитованными персонами — т.е. надо нанимать адвокатов. Хороший адвокат с рекоммендациями стоит $450 в час, и часов нужно много — десятки, если не сотни. Никакой "бесплатной защиты", как в кино, не положено, потому как это не уголовный иск, а гражданский. Всё за свои.
Обжегшись, начал читать договоры внимательно. И да, в сложных случаях нанимаю адвоката — это несоизмеримо дешевле, чем судебные издержки. И да, торгуюсь об условиях трудового договора. Обычно получается.
Один раз пришлось отказаться, т.к. в договоре были прописаны совершенно дичайшие вещи — компания получала право в любой момент затребовать у меня все имеющиеся документы, электронные устройства, носители, и т.д., с целью контроля, а не тырю ли я их конфиденциальную информацию. И не только в течение трудоустройства, но и 3 года после увольнения. И в течение этого срока я также обязался отчитываться перед компанией, где я живу, на кого работаю, на каких условиях, чем конкретно занимаюсь, и т.д. Плюс ещё несколько интересных пунктов.
Адвокат, честно, ох... немножечко впал в оторопь и посоветовал не соглашаться, что в общем и так было понятно. Нанимающий менеджер тоже впал в тихую оторопь после того, как я в переписке озвучил претензии к пунктам договора и привёл анализ адвоката, и начал блеять на тему: Но мы же никогда… Но это же просто рыба… Да вообще!
Что интересно, через пару месяцев после отказа они таки вернулись и сказали, что пофиксили договор, может, чёрт возьми, нам снова?.. Но паровоз уже отчалил.
Немаленький финтех-стартап в SF это был, дочка немаленького лидера на рынке онлайн CRM систем.
Дожив до возраста и доходов, позволяющих работать по 12-14 часов в день в выделенном домашнем офисе, обставленном мебелью Herman Miller, я понял, что уже вполне могу себе позволить не работать по 12-14 часов в день.
Можно ж хобби не только для себя, а и для народа тоже :)
Что вы, всё уже украдено до нас. :) Например: http://www.owwm.org. Я там в режиме чтения участвую, ибо добавить к этому кладезю знаний мне почти нечего.
Спасибо за фото и пояснения, теперь стало понятно, о чём вы говорили. Такие станки сделать действительно не проблема, при наличии рабочего пространства (пыли будет много), большого количества времени и достаточного опыта. Что-то мне подсказывает, что вы подходили к этому делу не совсем с нуля. Ну, или просто у меня руки кривые и мой опыт здесь плохо применим. :)
Я оставлю за кадром эксплуатационные вопросы. Например, как фанерный стол и направляющая реагируют на изменения температуры и влажности, и т.д.
Вполне допускаю, что для ваших задач точность вполне допустимая получается даже с учётом всех движений деревяшек. Или вопрос с отводом пыли. Вполне допускаю, что у вас есть отдельная мастерская и пыль для вас не проблема.
Но тут есть другой момент: ваши задачи для этих станков сводятся к самым простым операциям с готовыми материалами. Каких-то чуть более сложных операций фанерный станок из старой циркулярки просто не потянет. Скажем, пазование без боли на нём не сделать, и что-то толще готового щита не распилить. Отрезать под углом (beveling)? Без шансов. Сделать прорези для стыков (tenoning)? Забудьте, не сойдётся. И т.д.
Я это говорю не для того, чтобы принизить ваши достижения, и не утверждаю, что возможности ваших станков не будут достаточны для многих начинающих. Тут вопрос в другом: мало кто сможет понять ограничения самодельных станков, будучи начинающим. Вы ниже приводите пример мастера-инструментальщика, который делает приспособы для каждой задачи. Так он именно потому так и делает, что он уже мастер и понимает, что он делает, почему именно так, и каким именно образом такой подход экономит его ценное время.
А когда человек начинает чем-то заниматься, он ничего толком не знает. И более универсальные инструменты как раз в помощь: увидел/вычитал методику, попробуй применить и посмотри, подходит тебе или нет. Промышленный станок легко позволит это сделать и, самое главное, снять большую долю неуверенности в своих действиях. "Это инструмент плохой или у меня руки из жопы?" Если инструмент хороший, то вопрос даже не стоит. :)
Кроме того, любые инструменты имеют погрешность. Деревянные инструменты, тем более самодельные, имеют погрешность более высокую, чем промышленные железные инструменты. В некоторых случаях, существенно более высокую. Понимать, как именно эта погрешность вылезет в конечном изделии, как это обходить, и какие запасы в размерах оставлять для доводки напильником — это непросто. Это и с опытом совсем непросто, а для начинающего столяра это добавит целое измерение фрустрации, к которому человек будет не готов. Потому что если посмотреть видосики на Йутубе, то всё это абсолютно не очевидно: там люди в основном хвастаются достижениями, но мало кто удосуживается указать на подводные грабли и подсказать, как их обойти. Всё выглядит так легко: вжик, бац-бац, и склеил. А на практике получается, что всё криво, косо, углы не сходятся, фанера нифига не плоская, ты её струбцинами, а коробка-то вышла кривая… И уже не поправишь.
Вы же в ИТ небось работаете, про понятие learning curve знаете. И что порог входа в технологию лучше понижать, тоже. Так вот, изготовление самодельных станков, особенно как первый шаг в столярном деле, эквивалентно задиранию кривой до небес. А покупка готовых инструментов, как ни парадоксально звучит, порог входа заметно понижает.
И, раз уж требуете фото — что ж стесняетесь приложить свои?
По двум причинам: а) я сейчас в командировке, б) этот шкаф я уже распилил. :) Очень много места занимал, зараза. А сама пила большого интереса не представляет, т.к. покупная.
Можно пример? Я, видимо, недостаточно глубоко копал MobX, мне не очевидно, как такой подход использовать.
Из формы или ещё откуда-нибудь. В вашем примере мы присваиваем значение переменной. Эту переменную надо где-то хранить, чтобы потом использовать в форме. Надо создавать класс для компонента, чтобы хранить
this.model, или функциональный компонент. Тоже ручная работа.Но это всё ерунда, а вот как заставить компонент перерисовываться на изменениях модели? https://mobx.js.org/refguide/observable.html ни слова об этом не говорит, зато перечисляет аж 5 правил конвертации значений, которые нужно знать. И исключения для MobX версии 4, о которых тоже надо знать.
Зачем? Чтобы сделать форму с тремя полями?
Для этого надо сперва понять, что он изменился. См. предыдущий пункт.
Я не видел таких примеров для React + MobX. В документации MobX есть много примеров использования MobX в вакууме, но мне это не интересно. Я по работе использую React, мне нужно, чтобы компоненты отрисовывались по изменению состояния.
Примеров с React без использования классовых компонентов я не нашёл. Плохо искал?
А куда вы этот код сделаете, и как будете вызывать, чтобы а) данные туда сложить, и б) данные оттуда вытащить? И когда?
Нет, мне правда интересно. Почему-то во всех примерах с MobX используются именно классы и тонна магии. Почему?
Спасибо за ссылку, я в MobX копал вполне глубоко. На мой взгляд, именно работа с классами является неестественным усложнением в большей части случаев.
Ну честно, вам когда форму с полями нужно сделать, зачем для этого нужно создавать класс, поля, методы для работы с ними, да ещё и обмазывать эти методы магией
@observable? В Statium всё гораздо проще: вот модель (API), вот поля с данными (initialState), вот список, какие значения куда скормить (Bind). И всё.А если в форме нужно показывать значение из вышестоящего состояния? Имя юзера, например, или поле из родительского компонента. В Statium банальнейше, в MobX больно (ручками).
Вы посмотрите пристальнее, вдруг понравится. От ненависти до любви один шаг. :)
С точки зрения этого бизнеса (или, вернее, менеджеров), вы тоже всё время хотите чего-то странного. Зарплаты, например.
Я хочу вдаваться в подробности на тему, почему "забить большой болт и всё" нельзя. Это отдельная большая тема.
Я вам о другом говорю: забить большой болт не работает. Можно забивать сколько угодно, это не поможет. Никак. Потому что у 95% пользователей всё равно будут разные браузеры, разные платформы, и разные устройства. От мощных десктопов до туповатеньких Chromebook, от последних iPhone до дешёвых китайских клонов какой-нибудь младшей модели Samsung Smartwatch. Какие критерии вы предлагаете использовать для исключения тех и этих, чтобы ваша жизнь была попроще? Назад в будущее, к This site is best viewed in IE6?
По вашим словам мне очевидно, что вы просто не владеете предметной областью. Так и должно быть, front end не ваша специализация. Это моя специализация, и я отлично знаю из опыта и толстой мозоли на лбу, почему нельзя "просто взять и сделать" сайт, чтобы всё работало и все были довольны.
Я стараюсь не вспоминать о битвах с нативным скроллингом документа, который есть сущее, адское зло — а виртуальный скроллинг это тоже сущее, адское зло. У меня в печёнках сидят поля ввода в HTML, обработка фокуса, маски и валидирование значений. Меня тошнит от touch events, от распознавания жестов по таймауту и ловли утёкших таймеров (ручками, всё ручками!). Я молча посылаю пламенные лучи ненависти и поноса в сторону HP, Lenovo и прочих умников, выпускающих лаптопы с тачскринами, которые никак особенно не определяются в браузере и потом к чертям ломают всю обработку событий, потому что смешать pointer events и touch events это — а чо, у нас в Windows работало? Я плачу кровавыми слезами каждый раз, когда мне нужно лезть в caniuse.com и подтверждать, какие фичи из CSS3 работают в последнем мобильном Сафари, а какие нет. И т.д. и т.п., конца и края этому нет (и не будет).
Можно всё это игнорировать, для личных проектов сойдёт — кому они нужны, кроме вас. А для коммерческих проектов не сойдёт, и игнорировать уже не получится. Добро пожаловать в добрый, светлый мир front end. :)
Это всё же не совсем то, о чём я говорил. Прокси-сервисы и middleware тоже ломаются иногда, настройки слетают, и всё такое.
Но в back end практически не бывает так, чтобы без каких-либо изменений в вашем коде/настройках/Dockerfile/K8s/whatever, вдруг внезапно всё сломалось и перестало работать.
А на frond end — легко. Домен третьесторонней интеграции кто-то добавил в чёрный список, и привет. Узнать об этом, кроме как из разъярённых воплей обиженных клиентов, вообще никак нельзя. Это не хаос?
При всём уважении, ваши слова только подтверждают разницу между "делал, и не раз" и "занимаюсь этим постоянно". Вы этот хаос или намеренно игнорировали, или просто не успели заметить.
Если даже не вдаваться в поэзию, то самый поверхностный анализ ситуации позволяет увидеть, что благодаря наличию:
… и т.д., и т.п., поверхность потенциально проблемной области в front end разработке в разы больше, чем в back end. Если не на порядки.
Просто для примера, из свежего: у вас в практике часто бывало, чтобы на серверной стороне в код без спросу внедрился случайный третьесторонний модуль и начал блокировать вызовы к каким-либо микросервисам? И его не убрать никак. А у нас это норма жизни, ad blockers или какие-нибудь расширения в браузере могут в любой момент поломать что угодно. И объясняй потом бизнесу, почему их интеграция с каким-нибудь Appcues не работает и как её починить (а починить нетривиально).
И таких ситуаций, факторов, ошибок, особенностей, да просто багов — сотни, тысячи их. И каждый день что-то новое.
Мы из Хаоса (tm).
Вот странно, какие всё же плохие и громоздкие подходы вы имеете в виду… На мой взгляд, Statium гораздо проще и понятнее того же Redux, да и MobX тоже.
А коллегам, между прочим, вполне понравилось. :)
Фух, спасибо, отлегло. А то я уже в исходники полез, вдруг что-то где-то течёт… :)
Ага, вот тут уже понятнее. Если честно, я с вами вполне согласен — React это не самое лучшее решение, как идеологически, так и практически. Но по разным совершенно не техническим причинам, React есть реальность, данная нам в ощущениях. Можно это оспаривать сколько угодно, но если вы сравните количество вакансий на React со всем остальным, то...
В общем, в заголовке репозитория так и написано: Statium это прагматичный подход к управлению состоянием в React. :)
Состояние это не компонент, состояние это просто набор данных. Компонентом является хранилище состояния, фактически это просто API для доступа к объекту с данными.
Необходимо ли было делать это API в виде компонента? Нет конечно, есть и другие варианты; у этого же подхода есть как минимум одно большое преимущество: лёгкость использования в функциональных/презентационных компонентах. Гораздо проще и быстрее написать вот такой код:
… чем функцию, которая что-то с чем-то соединяет, или
@observableмагию, которая рассыпается без поддержки декораторов, etc.Да, вы правы. В какой-то момент мне надоело бодаться с ветряными мельницами. If you cannot beat them, join them и всё такое.
Тем более, что если допустить, что с какой-то точки зрения React вполне себе работает, то может, и ладно? Работает себе, давайте используем существующие механизмы. В конце концов, зарплату платят за фичи. :)
Вполне возможно, что оно так выглядит из-за плохого изложения материала. Над документацией мне ещё работать и работать, это факт. Потому что с моей точки зрения, абстракций в ViewModel как раз почти нет: это тупо тот же самый
setState, только вынесенный в отдельный компонент.Понятно, раздел с анализом производительности надо поднять наверх. :) Я его в конец README засунул, так не работает.
Вообще всё с точностью до наоборот: ViewModel работает безобразно быстро. Т.е. настолько, что я сколько ни пытался профилировать на работающих приложениях, ViewModel и сопутствующий код даже не заметно в Call Tree, надо очень глубоко копать.
А если подумать, то чему там тормозить? Собственно данные ViewModel лежат в обычном объекте, который связан по прототипной цепочке с родительскими объектами. Чтение по ключу из объекта это как раз то, что JavaScript умеет делать очень быстро. :)
Обновление состояния тоже ненамного дороже родного для React
this.setState(). А поскольку ключ обновляется в модели-владельце, то рендеринг отрабатывает только для этой модели и её детей. Ну т.е. в самом худшем случае, если у вас абсолютно все ключи в одной модели в корне приложения, получаете такой как бы аналог Redux. :)Но соль-то как раз в том, что запихивать всё состояние в одну модель просто нет надобности. В Redux так делают из-за официальной рекомендации свыше, но на мой взгляд, причина очень проста: больше одного store в Redux это очень, очень больно. Нужно вручную устанавливать и отслеживать все связи, изменения, и т.д.
А в Statium всё просто: каждая модель автоматически имеет доступ к родительским данным, и вы просто можете их использовать там, где нужно. И любимая проблема: упс, я задал ключ foo вот здесь, а он нужен ещё вон там в соседнем компоненте, решается банально переносом одного свойства в родительскую модель. И всё просто работает. :)
Спасибо за отзыв. :) Можно поинтересоваться, что именно вызвало у вас такую реакцию? Концепция хранения данных в компоненте, иерархическая связь, кривизна API, или код примера? Или всё вместе? Ну правда, интересно же. :)
Спасибо за критику, очень интересно. Можно по пунктам?
А почему нет? Этот подход идеологически ничем не отличается от
this.setState()в компонентах; практически разница только в том, что состояние делегировано в отдельный, предназначенный для этого компонент. Специализированность компонента позволяет решать проблемы доступа к данным без текущих абстракций, а то, что хранилище является компонентом, позволяет использовать все оптимизации, наработанные в React с его появления.Внутри ViewModel используется именно
setState, вполне ванильно.Подождите, какой DOM? ViewModel ничего не рендерит в DOM, это виртуальный компонент с хранилищем для данных. Или я как-то не так вас понял?
Глас вопиющего в пустыне… Людям, которые работают с простыми, очевидными, и прекрасно контролируемым условиями в back end, никогда не понять хаоса и дикого Запада front end.
Ни то, ни другое. Надо использовать (бесстыжая самореклама!) Statium: https://github.com/riptano/statium. RealWorld example: https://github.com/nohuhu/react-statium-realworld-example-app
State colocation из коробки, наглядно, и, что самое важное — с доступом к состоянию родительских компонентов, тоже из коробки. И многое другое.
Всё верно, только не как будто. Это и есть аргументация в суде против вас.
Я тоже не особо читал договоры и верил в человеческую порядочность, пока не привелось получить судебный иск на миллион долларов от бывшего партнёра и работодателя в своё честное, открытое физическое лицо, проживающее в социалистическом штате Канифольния. В процессе узнал много нового и интересного, например: если на вас подали иск и вы не подали прошение о защите, то истец признаётся правым автоматически, и получает всё, что запросил. Это закон. Процесс защиты долгий и сложный, документы должны быть подготовлены аккредитованными персонами — т.е. надо нанимать адвокатов. Хороший адвокат с рекоммендациями стоит $450 в час, и часов нужно много — десятки, если не сотни. Никакой "бесплатной защиты", как в кино, не положено, потому как это не уголовный иск, а гражданский. Всё за свои.
Обжегшись, начал читать договоры внимательно. И да, в сложных случаях нанимаю адвоката — это несоизмеримо дешевле, чем судебные издержки. И да, торгуюсь об условиях трудового договора. Обычно получается.
Один раз пришлось отказаться, т.к. в договоре были прописаны совершенно дичайшие вещи — компания получала право в любой момент затребовать у меня все имеющиеся документы, электронные устройства, носители, и т.д., с целью контроля, а не тырю ли я их конфиденциальную информацию. И не только в течение трудоустройства, но и 3 года после увольнения. И в течение этого срока я также обязался отчитываться перед компанией, где я живу, на кого работаю, на каких условиях, чем конкретно занимаюсь, и т.д. Плюс ещё несколько интересных пунктов.
Адвокат, честно,
ох...немножечко впал в оторопь и посоветовал не соглашаться, что в общем и так было понятно. Нанимающий менеджер тоже впал в тихую оторопь после того, как я в переписке озвучил претензии к пунктам договора и привёл анализ адвоката, и начал блеять на тему: Но мы же никогда… Но это же просто рыба… Да вообще!Что интересно, через пару месяцев после отказа они таки вернулись и сказали, что пофиксили договор, может, чёрт возьми, нам снова?.. Но паровоз уже отчалил.
Немаленький финтех-стартап в SF это был, дочка немаленького лидера на рынке онлайн CRM систем.
Дожив до возраста и доходов, позволяющих работать по 12-14 часов в день в выделенном домашнем офисе, обставленном мебелью Herman Miller, я понял, что уже вполне могу себе позволить не работать по 12-14 часов в день.
Чего и вам желаю.
Из альтернатив кроме ag-Grid есть ещё Bryntum Grid.
5 лет, полёт нормальный.
Ну беруши же.
Что вы, всё уже украдено до нас. :) Например: http://www.owwm.org. Я там в режиме чтения участвую, ибо добавить к этому кладезю знаний мне почти нечего.
Вы почему-то воспринимаете два этих занятия, как взаимоисключающие. Это просто хобби, сегодня одно, завтра другое. :)
А перепродавать точно не буду, это совершенно невыгодно. Затраты по времени никогда не окупить.
Спасибо за фото и пояснения, теперь стало понятно, о чём вы говорили. Такие станки сделать действительно не проблема, при наличии рабочего пространства (пыли будет много), большого количества времени и достаточного опыта. Что-то мне подсказывает, что вы подходили к этому делу не совсем с нуля. Ну, или просто у меня руки кривые и мой опыт здесь плохо применим. :)
Я оставлю за кадром эксплуатационные вопросы. Например, как фанерный стол и направляющая реагируют на изменения температуры и влажности, и т.д.
Вполне допускаю, что для ваших задач точность вполне допустимая получается даже с учётом всех движений деревяшек. Или вопрос с отводом пыли. Вполне допускаю, что у вас есть отдельная мастерская и пыль для вас не проблема.
Но тут есть другой момент: ваши задачи для этих станков сводятся к самым простым операциям с готовыми материалами. Каких-то чуть более сложных операций фанерный станок из старой циркулярки просто не потянет. Скажем, пазование без боли на нём не сделать, и что-то толще готового щита не распилить. Отрезать под углом (beveling)? Без шансов. Сделать прорези для стыков (tenoning)? Забудьте, не сойдётся. И т.д.
Я это говорю не для того, чтобы принизить ваши достижения, и не утверждаю, что возможности ваших станков не будут достаточны для многих начинающих. Тут вопрос в другом: мало кто сможет понять ограничения самодельных станков, будучи начинающим. Вы ниже приводите пример мастера-инструментальщика, который делает приспособы для каждой задачи. Так он именно потому так и делает, что он уже мастер и понимает, что он делает, почему именно так, и каким именно образом такой подход экономит его ценное время.
А когда человек начинает чем-то заниматься, он ничего толком не знает. И более универсальные инструменты как раз в помощь: увидел/вычитал методику, попробуй применить и посмотри, подходит тебе или нет. Промышленный станок легко позволит это сделать и, самое главное, снять большую долю неуверенности в своих действиях. "Это инструмент плохой или у меня руки из жопы?" Если инструмент хороший, то вопрос даже не стоит. :)
Кроме того, любые инструменты имеют погрешность. Деревянные инструменты, тем более самодельные, имеют погрешность более высокую, чем промышленные железные инструменты. В некоторых случаях, существенно более высокую. Понимать, как именно эта погрешность вылезет в конечном изделии, как это обходить, и какие запасы в размерах оставлять для доводки напильником — это непросто. Это и с опытом совсем непросто, а для начинающего столяра это добавит целое измерение фрустрации, к которому человек будет не готов. Потому что если посмотреть видосики на Йутубе, то всё это абсолютно не очевидно: там люди в основном хвастаются достижениями, но мало кто удосуживается указать на подводные грабли и подсказать, как их обойти. Всё выглядит так легко: вжик, бац-бац, и склеил. А на практике получается, что всё криво, косо, углы не сходятся, фанера нифига не плоская, ты её струбцинами, а коробка-то вышла кривая… И уже не поправишь.
Вы же в ИТ небось работаете, про понятие learning curve знаете. И что порог входа в технологию лучше понижать, тоже. Так вот, изготовление самодельных станков, особенно как первый шаг в столярном деле, эквивалентно задиранию кривой до небес. А покупка готовых инструментов, как ни парадоксально звучит, порог входа заметно понижает.
По двум причинам: а) я сейчас в командировке, б) этот шкаф я уже распилил. :) Очень много места занимал, зараза. А сама пила большого интереса не представляет, т.к. покупная.