Что плохого в деструктуризации?

снижается читаемость кода. он становиться менее предасказуемым. куда лучшче четко видеть что и откуда props.item - понятно что взяли данные из пропсов item - что это? надо идти смотреть а откуда этот item на код ревью (где не так все хорошо с просмотром кода и часто мы не видим весь код) item.title = “some” - вроде все ок props.item.title = “some” - вообще не ок, пропсы нельзя мутирвоать

Плохого ничего и тот и другой подход имеет право на жизнь, но есть аргументы в + отказа от деструктуризации Я лично тоже против неё в пропсах

Мне кажется наоборот неиспользуя деструктуризацию код тяжелее читать Что лучше item.id, Item.food, Item.chunk, Item.totalPrice Или const { id, food, chunk, totalPrice } = item:

первое

Аргументы?

я выше расписал

Субъективщина значит

субьектно на код ревью не видно откуда и что это за id?

Речь не про деструктуризацию в целом, а только в контексте пропсов

Если в компоненте всего 1 цикл и 1 ацди то деструктуризация круче

а если не один?

Разбивать компоненты так чтобы были по 1 циклу мб

а если у меня это именно специфика компонента?

если так то так если не так то эдак… Зачем иметь такие сложные стандарты написания кода? нужно иметь одно решение для одной задачи

Нет аргументов у меня для этого) Интересная позиция, пересмотрю своё отношение к коду других людей, когда делаю рефактор их кода в деструктуризацию

потому что источкник данных важен? item.title = “some value” - это валидный код?

Я немного не пойму, если к тебе в компонент приходит item, зачем ты его перезаписываешь? Может мы про разные вещи говорим.

дак в том то и дело что в этом строчке не понятно, это что-то что пришло из вне или что-то локальное (ведь все так любят разбирать пропсы на части)

Ну вот у меня есть компонент, я все таки не пойму почему этот код плох из-за деструктуризации ? Мне кажется ты что-то другое прям имеешь ввиду

Во время код ревью ты смотришь не весь файл а участок с изменениями. Изменения могут не затрагивать вышестоящий код и хрен пойми это пропс, стейт или вообще просто переменная левая или вообще импорт откуда-то

а давай расмотрим пример более сложного компонента и при этом не в редакторе а в diff пул реквета на гитхабе

Тогда тебе тем более не нужно знать, что там происходит, грубо говоря, смотри на изменяемую строчку, что поменялось в логике или синтаксисе

шта, впервые вижу, чтобы деструктуризацию кто-то хейтил, особенно в аргументах

я старый и ленивый человек, зачем мне весь этот оверинжениринг? 😂 когда на тебе висит 5 пул реквестов и все надо просмотреть вчера - ни о каком покомитно и речь быть не может. Тем более что далеко не все “покоммитно” все делают

если отказ от нее приводит к более читаемому коду -то зачем она нужна? ну кроме случаев когда она нужна чтобы выкинуть какие то значения из объекта)

хотя учитывая что обычно это используется в связе со спред оператором, а у него тоже есть явные противники, то получается что опереатор деструктуризации вообще не нужен 😂 на самом деле дофига чего добавляют в язык что люди начиются использовать не по назначению и скорее ухудшают код в угоду “ой тут меньше символов писать”

Ну тогда это не код ревью) да и энивэй, проще поставить локально, глянуть что все билдится, затем посмотреть на сайте. То что будет item.Id или Id не особо повлияет

что все билдиться провереся не локально, а на ci/cd

Ну у нас саяйсиди настроен на девелоп ветку, отдельные ветки не деплоятся. Поэтому чтобы узнать что сбилдилось нужно либо настраивать сияйчиди для веток целиком/пул реквестов, либо делать тестовый пуш в девелоп и откатываться назад если что (говно варик)

"надо идти и смотреть а откуда этот item" Так нефиг делать компоненты в 100500 строк...

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

+

1. Нажать кнопочку, чтобы показать ещё 20 строк - совсем не проблема 2. Согласен, но декомпозицию не просто же так придумали) отделение логики от view и т.п. 3. Это не значит, что не надо стремиться к лучшему)

2 - не объязательно речь про логику Вью может быть большим и неделимым. Например очень большая форма

На степ форму делите. Не делайте моих глупых ошибок

Ну это скорее исключение... Хотя некоторые формы легко делятся на смысловые блоки

Зависит от дизайна Степ форма может быть даже лишней

Но к сожалению не все

Я и говорю, скорее исключение

Ну в форму на 20 полей тяжко заполнять, а вот 4 по 5 уже легко

Ну даже 5-8 уже компонент может быть не самым маленьким Как минимум на 70 строк растянуть можно если атрибутов много используется и юз эффектов всяких

Можно вопрос по рефакторингу? У меня есть на сайте таблица для десктопа и лист айтемс для мобилки Верстка примерно идентичная. Логично было бы сделать общий компонент РоуАйтем, и ещё логично было бы общий компонент, где по пропсе view=“table” | “list” рендерить роуайтемы Так вот, стоит ли оставить дублирование кода или пихнуть все в 1 компонент с пропсой вью?

Я всегда пушу разделение на степы по логическим блокам: 1) Основная инфа 2) Какие-то даты 3) Что-то другорядное ...

Тогда можна будет эти степы ещё переюзать в другой форме🙃

Мб пропса не нужна и достаточно класса модификатора решая всё на уровне цсс

Ну, это хорошо, очень, не спорю Но к сожалению не универсально

слишком абстрактно) по умолчанию выглядит как совсем разное представление, я бы скорее разбил на два компонента. Но надо смотреть конкретнрый случай

Попробуй посмотреть под призмой принципа Барбары-Лисков. Вынеси всё общее у них, в отдельный компонент. А всё что различаеться в другой. Если не получаеться вынести, значит ненадо.

Нужна, там нужно менять верстку целиком

Ну вот я и решил что повторяется у них более менее <TableRow> и <BoxRow>

Думал над твоим вопросом вчера. Вот это видео наверное немного прояснит тебе ситуацию. Поставил таймкод, там минут 5, после него у тебя должны отпасть все вопросы по поводу изменяемости, так как у тебя в коде . И тогда деструктуризация не будет тебе мешать. https://youtu.be/JRA2JpqAjlw?t=275

Вообще не понял как это решает проблему?

Про декларативность не соглашусь, вот тоже ссылка с привязкой ко времени, там про пример из реальной жизни. (совсем начало разговора про декларативность чуть раньше)

Вот он четко объясняет почему так не стоит делать, как ты предложил. Нужно следить за чистотой функции, тогда и не будет таких проблем.

а я говорил что надо менять?)) я как раз говорил что если использвоать деструктуризацию то не понятно что ты менешь - внешний параметр или что-то локальное для функции

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

перечитай еще раз то что я говорил

Перечитал, тогда почитай про функции и побочные эффекты, и хорошо это или плохо.

да причем тут побочные эффекты?

Потому что ты написал, не понимаешь меняет она внешне или что-то внутри.

item.title = “some” меняет что-то внешнее или нет?

из кода не понятно в этом и дело задача как раз и проверить чтобы не меняло

Если чистая функция, то нет

ват

извини но гитхаб как бы не подписывает какие функции чистые а какие нет

мутабельность под суд

Для этого ты и делаешь код ревью, нужно доносить это джунам, что бы они так не делали ))

дак в том то и дело что деструкрутазция мешает делать код ревью

В твоем примере происходит мутация, а в чистых функциях мутации не происходят

Да не мешает она ничего, научи своих бойцов один раз, и не будет у тебя таких вопросов.

пиздец ты наивный

Ты статью читал, или просто ляпнул что увидел ?

У тебя спросили: item.title = “some” меняет что-то внешнее или нет? Ты ответил: Если чистая функция, то нет Хотя в чистой функции невозможно item.title = “some”

Хорошо, так она меняет что-то внешне или нет ? Если это чистая функция

как это невозможно?

а, ну ты действительно фигню сказал

что именно фигня ? Можно конкретнее ?

Если мы не хотим ничего мутировать, то нужно const newItem = {…item, title: “some”}

зачем хотеть ничего не мутировать?

Ты передаешь же откуда-то объект item в функцию и мутируешь его переопределяя title

Может я его внутри создаю

я нет, он да. И как это по твоему, хорошее поведение для чистой функции ?

Думаю что не очень

Ну вот,тогда не пойму претензию к моему высказыванию, в виде твоего "ват"

(где-то я уже писал об этом, не смог найти где) Не соглашусь, ревью - это очень частый пример и если какие-то инструменты его мешают делать - нужно фиксить инструменты. А когда ты работаешь с кодом уже в редакторе при дебаге, например, ты видишь в JSX какие-то props.some.where, но таких штук раскидано 10-15, а в начале реднера ничего нет и не понятно какие данные компоненту реально нужны. Хорошая практика - разделять объявление / вычисление данных и их отображение. Все что нужно в шаблоне нужно сначала вытащить и предрасчитать в понятные переменные, а потом напрямую использзовать.

а при мемоизации так не будет возникать проблем? предположим, что компонент получает какую-то пачку пропсов, часть из них уходит в useMemo, useCallback и при использовании зависимостей в виде props.item.lalala в комбинации с преттиром массив deps будет раздуваться по линиям кода

большое кода(точнее символом) не значит хуже

согласен