Pull to refresh
-5
0
Send message

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

Давайте я вам помогу лучше.Так будет нагляднее.

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

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

c mobX еще проще - т.к. там действий меньше. меньше действий => проще понять что происходит.

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

в mobX работа идет на уровне свойств стора. помогает ide и компилятор, что еще 'более безопаснее'.

Редактор кода подскажет методы создания реактивных переменных и работы с ними.

И наверное подскажет то, что при вызове store.getAtom() передано неправильное имя свойства стора?

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

просто Ваша либа не умеет в автоматические подписки.

Выделил отдельно код по кейсу с двумя переменными:

  1. mobx

autorun(() => {
  counter1div.innerHTML = `counter 1: ${state.counter1}`;
  counter2div.innerHTML = `counter 2: ${state.counter2}`;
});
  1. Ваше

counter1div.innerHTML = `counter 1: ${state.counter1}`;
counter2div.innerHTML = `counter 2: ${state.counter2}`;

const counter1 = store.getAtom('counter1');
const counter2 = store.getAtom('counter2');

store.onChangeAny([counter1, counter2], () => {
  counter1div.innerHTML = `counter 1: ${state.counter1}`;
  counter2div.innerHTML = `counter 2: ${state.counter2}`;
});

Вы правда считаете, что распухание кода в 2 раза, копипаста и boilerplate ведет к увеличение читабельности кода?

У этого монитора есть как минусы так и недостатки.

  1. Вы упростили пример - нету кейса когда необходимо делать реакцию на изменения 2 свойств. судить о читабельности - рано кмк.

  2. Необходимо явно подписываться на изменения свойств - при рефакторинге, изменении требований, etc - легко забыть подписаться на нужное свойство/отписаться от ненужного. Да и не хочется этим заниматься.

  3. В коде используются магические константы - при рефакторинге/наборе можно перепутать.

А вас есть пример делающий тоже самое?

Имхо сравнивают с mobx и понимают что mobx лучше.

Он не прибит к реакту. Посмотрите примеры из самого mobx.

Linq Skip и Take это по-моему база. Неужели трудно повторить базу перед прохождением собеса? Ну и TL оценивают и как разработчика при прохождении интервью.

Без DI у Вас не получилось. Вы написали то что делает обычный IOC контейнер, но в ручную.

Ну и в примитивном случае "прогать на интерфейсах" можно. но что если вложенность будет хотя бы 3?

и "const someX: X = new A();" - это уже не "прогать на интефейсах", а жесткая завязка на реализацию interface X, что усложнит как минимум тестирование.

Где тут run-time зависимости? Как вы без DI тесты юнит тесты пишете?

Поясните пожалуйста, почему отказ от поколений gc уменьшит количество stop world? Интуитивно кажется что это не должно никак повлиять, но и даже наоборот, отказ спровоцирует увеличение продолжительности stop world...

пруфа, конечно же, не будет

Вероятно из за сертификации в Европе нолик порезали

Как странно видеть manual reset event и Task.Run вместе

При таких вводных проще будет сразу писать хранимую процедуру в бд.

p.s. зачем план запроса строить на этапе компиляции?

  1. Cубд умеют кэшировать планы запросов.

  2. Планы запросов имеют тенденцию устаревать - ну там статистка, индексы и вот это все

"какая погода в Москве" ваше решение тоже что то странное выдает

Information

Rating
Does not participate
Registered
Activity