React Drag & Drop: «Игра в бутылки»

[jamwid07]

Почему эта комбинация неправильная. Она же логически верная

Ответ

[wayvy]

Благодарю за внимательность! В правилах не учел этого варианта, уже исправил.

[faiwer]

Немного критики.

get isOneAtBottomCorrect(): boolean {
        return correctPositions.some(

Плохая идея использовать в getter-е что-то что работает за O(n).

return (
  JSON.stringify(correctPositions) ===
  JSON.stringify(this.positions[ShelvesEnum.top]) // элегантный способ 🤨
);

Один из вопросов на собеседованиях почему это не "элегантный способ" а треш. Come on.

<Rules>
  {rules.map((rule, i) => (
    <li key={i}>{rule}</li>
  ))}
</Rules>

Лучше так:

<Rules rules={rules}/>

Вы уже выделили под это компонент. И даже назвали его rules. Но зачем-то передаёте туда children prop. Не очень логично, имхо. Да и не должно быть никаких <li/> на таком высоком уровне иерархии.

Ну и самое главное, у вас для drag-n-drop используется React-way. Т.е. rerender на каждый onMouseMove. Мягко говоря не производительный вариант. Для такой простой задачи может быть ещё и сойдёт, но я не рекомендую такое тащить в более сложные кейсы. Там 99% времени CPU будет заниматься чем угодно, но не D-n-D.

[Alexandroppolus]

Плохая идея использовать в getter-е что-то что работает за O(n).

Если геттер под мобиксовый компутед, то вполне.

[faiwer]

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

[wayvy]

Ну и самое главное, у вас для drag-n-drop используется React-way.

Естественно, ведь статья называется React Drag & Drop. Может быть есть какой-то совет по оптимизации?

Плохая идея использовать в getter-е что-то что работает за O(n).

Computed-getters в MobX мемоизируются.

Один из вопросов на собеседованиях почему это не "элегантный способ" а треш. Come on.

Конечно же, треш. Подумал, что саркатистичный комментарий указывает на это. Впредь буду аккуратней!

Вы уже выделили под это компонент. И даже назвали его rules. Но зачем-то передаёте туда children prop. Не очень логично, имхо. ...

Здесь Rules не функциональный, а styled-компонент. Не хотелось в примере плодить компоненты, которые не связаны с темой статьи. Вообще, конечно же, стоит выносить рендер списков в отдельные компоненты.

[faiwer]

Может быть есть какой-то совет по оптимизации?

Ага. Делать наиболее критичные по performance-у вещи в обход React-а. Это актуально как для анимаций, так и для таких вещей как d-n-d. Сердцем любого d-n-d являются event-handler-ы вроде onMouseMove. Вот там внутри можно вручную править координаты, не задействуя React вообще. Просто через доступ к DOMElement-у.

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

А, тогда пардон. Мой мозг сломан десятками проведённых интервью. Где народ на полном серьёзе указывает, что это true way. Вот я и не уловил сарказма :)

[Alexandroppolus]

Computed-getters в MobX мемоизируются.

но только пока за ними наблюдают, либо если они "keepAlive". Конкретно в вашем примере за isOneAtBottomCorrect не бывает наблюдений, и её действительно нет особого смысла делать геттером - всё равно при каждом вызове будет пересчет.