Size: a a a

2020 March 05

ОХ

Олег Хлевнов in JSNN 🤔 (GSNN)
Это прекрасное
источник

E

Evgeniy 🍀 in JSNN 🤔 (GSNN)
умные люди вроде Дяди Боба говорят, что поддержка и расширение продукта - это самая дорогостоящая часть эксплуатационного цикла.

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

Поддерживать мешанину из классов с декорированными методами, геттерами, сеттерами и computed properties, особенно написанную чужими руками -  удовольствие ВЕСЬМА сомнительное.
Красивый и поддерживаемый OOP-style код на JS вообще вряд ли возможен.
Поэтому я и близко не подхожу к MobX.
источник

SS

Sergey Smyshlyaev in JSNN 🤔 (GSNN)
N Gafarov
Если этот говнокод размазать по пяти разным файлам (как в редаксе), то сильно лучше не станет
Есть один существенный и принципиальный недостаток мобикса по сравнению с редаксом: все твои компьютерды буду считаться каждый раз при изменении данных, даже если никакому вью они не нужны. Из-за этого будут постоянно вылетать всякие ошибки про null и отсутствющие методы и необходимо чтобы данные всегда были в консистентном состоянии, даже если по факту эти данные сейчас никто не использует. В редаксе такого нет, потому что селекторы выполняются тогда когда рендрится вью.
источник

NG

N Gafarov in JSNN 🤔 (GSNN)
Evgeniy 🍀
умные люди вроде Дяди Боба говорят, что поддержка и расширение продукта - это самая дорогостоящая часть эксплуатационного цикла.

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

Поддерживать мешанину из классов с декорированными методами, геттерами, сеттерами и computed properties, особенно написанную чужими руками -  удовольствие ВЕСЬМА сомнительное.
Красивый и поддерживаемый OOP-style код на JS вообще вряд ли возможен.
Поэтому я и близко не подхожу к MobX.
Один класс - одна доменная область. Данные + методы для работы с этими данными в одном месте - это удобно. Так еще наши диды писали. Так пишет ангуляр и ембер сообщество. Ноль проблем с поддержкой.
В это же время реакт сообщество уже пятый год не может понять как создать переиспользуемый компонент (миксины, декораторы, хоки, хуки).
источник

NG

N Gafarov in JSNN 🤔 (GSNN)
export class CartService {
 items = [];

 addToCart(product) {
   this.items.push(product);
 }

 getItems() {
   return this.items;
 }

 clearCart() {
   this.items = [];
   return this.items;
 }
}

мы пишем так же на мобиксе. пример с https://angular.io/start/start-data
источник

NG

N Gafarov in JSNN 🤔 (GSNN)
тоже самое на ембере https://guides.emberjs.com/v2.1.0/applications/services/ (см. app/services/shopping-cart.js)
источник
2020 March 06

E

Evgeniy 🍀 in JSNN 🤔 (GSNN)
N Gafarov
Один класс - одна доменная область. Данные + методы для работы с этими данными в одном месте - это удобно. Так еще наши диды писали. Так пишет ангуляр и ембер сообщество. Ноль проблем с поддержкой.
В это же время реакт сообщество уже пятый год не может понять как создать переиспользуемый компонент (миксины, декораторы, хоки, хуки).
Всё звучит разумно, только непонятно, причем тут MobX и как это связано с неспособностью реакт сообщества найти единственно верный путь (что кстати можно расценить как действующий пример демократии)

Насчёт дедов и ооп - ООП стиль (Который ТРУЪ, на классах с конструкторами) даёт вроде бы большую свободу, но требует странных и искуственных ограничений вроде паттернов проектирования (которые вообще были взяты частично из архитектуры и частично из промышленности) Которые нужны, чтобы разные разработчики понимали друг друга.

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

Современные ЯП как раз и созданы в значительной мере для того, чтобы избавить разработчика от этого геморроя (недаром в самых свежих и популярных на бэке языках аля Go/Rust нет классового наследования и завозить не планируется) Зачем писать на классах в JS, имея first class citizen функции - для меня тайна, покрытая мраком.
источник

NG

N Gafarov in JSNN 🤔 (GSNN)
Evgeniy 🍀
Всё звучит разумно, только непонятно, причем тут MobX и как это связано с неспособностью реакт сообщества найти единственно верный путь (что кстати можно расценить как действующий пример демократии)

Насчёт дедов и ооп - ООП стиль (Который ТРУЪ, на классах с конструкторами) даёт вроде бы большую свободу, но требует странных и искуственных ограничений вроде паттернов проектирования (которые вообще были взяты частично из архитектуры и частично из промышленности) Которые нужны, чтобы разные разработчики понимали друг друга.

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

Современные ЯП как раз и созданы в значительной мере для того, чтобы избавить разработчика от этого геморроя (недаром в самых свежих и популярных на бэке языках аля Go/Rust нет классового наследования и завозить не планируется) Зачем писать на классах в JS, имея first class citizen функции - для меня тайна, покрытая мраком.
Смотри, мне не нужны адаптеры, фабрики и компоновщики, потому что из файла с мобикс-стором ("сервисом" в понятиях ангуляра) я экспортирую инстанс, а не сам класс.
У меня нет геморроя с классовым наследованием потому что я не наследую стор от стора.

Не думай о мобиксе как о ООП, думай как о FRP без необходимости руками подписываться и отписываться.
источник

NG

N Gafarov in JSNN 🤔 (GSNN)
Это не холивар между ООП и ФП. Это холивар между TFRP и сраным window.state={} вокруг которого вертится евентбас. А чтобы это говно хоть как-то работало, сверху нужно добавить saga/thunk/observable. Плюс reselect, normalize, immutable-js и еще пару библиотек.
источник

m

mg901 in JSNN 🤔 (GSNN)
Ребята, кто сегодня был на Beer JS. Если кому вдруг интересно стало потрогать эффектор и ощутить в деле «что же такое этот эфеектор?». С радостью буду рад видеть вас в нашем уютном чате. Не стесняйтеь, задавайте вопросы. Будьте в курсе последний изменений, выдвигайте свои идеи. В общем всем всегда рады. https://t.me/effector_ru
источник

IE

Ivan Eroshkin in JSNN 🤔 (GSNN)
mg901
Ребята, кто сегодня был на Beer JS. Если кому вдруг интересно стало потрогать эффектор и ощутить в деле «что же такое этот эфеектор?». С радостью буду рад видеть вас в нашем уютном чате. Не стесняйтеь, задавайте вопросы. Будьте в курсе последний изменений, выдвигайте свои идеи. В общем всем всегда рады. https://t.me/effector_ru
источник

m

mg901 in JSNN 🤔 (GSNN)
typescript 3.8.3 + react + webpack + vscode. Подскажите пожалуйста. Как юзать
import type {MyType} from ‘./types
источник

m

mg901 in JSNN 🤔 (GSNN)
у меня линтер всё сразу кровью заливает.
источник

E

Evgeniy 🍀 in JSNN 🤔 (GSNN)
а import { MyType } from './types' чем не устроил?
источник

ОХ

Олег Хлевнов in JSNN 🤔 (GSNN)
👍
источник

E

Evgeniy 🍀 in JSNN 🤔 (GSNN)
mg901
у меня линтер всё сразу кровью заливает.
а вообще, есть подозрение что твой линтер не может в type-only imports, так как релизнули их буквально неделю назад
источник

m

mg901 in JSNN 🤔 (GSNN)
только что с чуваком переписывался. У него такой проблемы нет https://github.com/hexagon141/tstest/blob/master/index.ts
источник

E

Evgeniy 🍀 in JSNN 🤔 (GSNN)
mg901
только что с чуваком переписывался. У него такой проблемы нет https://github.com/hexagon141/tstest/blob/master/index.ts
ок, держи в курсе переписки 😅
источник

m

mg901 in JSNN 🤔 (GSNN)
Evgeniy 🍀
ок, держи в курсе переписки 😅
ты чего сегодня, не с той ноги встал? Я тебе про решение проблемы, ты мне про хуйню левую.
источник

A

Anton in JSNN 🤔 (GSNN)
ребята, полегче
источник