спасибо )

Главное чтобы работало идемпотентно, state.getIn([а, 10, 32]) === state.getIn([a, 10, 32]) не смотря на разницу ссылок на ключи и отсутствующие элементы в коллекции

я решил не полагаться на наличие состояния, создаваемый мной объект является ключём эквивалентность которого можно проверить ===, плюс у меня задача делать такое: state.getIn([a, [1, 2, 10], 32]) => []

Это работает именно так как ты описал, здесь нет противоречия. Уже работает.

Помимо всего прочего, состояния здесь тоже нет это ж иммутабл

но в таком подходе нельзя проверить эквивалентность ключей не перебрав массивы и не имея возможности getIn

ребзи а пояните чем подход с иммутабельностью лучше ?

вот в mobx сделали все на мутациях и не парятся

ребзи а пояните чем подход с иммутабельностью лучше ?

За такие вопросы уу....юю

вот в mobx сделали все на мутациях и не парятся

на обсерверах?

на обсерверах?

да

это не мутации, это обсерверы

ребзи а пояните чем подход с иммутабельностью лучше ?

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

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

ну так вы ж я так понял свои стейт менеджеры пишете

это не мутации, это обсерверы

но там можно мутировать же

ну так вы ж я так понял свои стейт менеджеры пишете

я перехожу на мутации

ну реально с большими коллекциями данных, тем более есть они сильно вложенные, иммутабельность превращается в боль

ну реально с большими коллекциями данных, тем более есть они сильно вложенные, иммутабельность превращается в боль

не всегда

последним аргументом к переходу на мутабельность для меня стала поддержка Map, Set и подобных

ну реально с большими коллекциями данных, тем более есть они сильно вложенные, иммутабельность превращается в боль

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

циклические ссылки ?

нет

A -> C B -> C

ну реально с большими коллекциями данных, тем более есть они сильно вложенные, иммутабельность превращается в боль

С чего вдруг?

A -> C B -> C

понял, когда ссылаются на одну сущность

С чего вдруг?

ну все уровни вложенности заново скопировать

ну все уровни вложенности заново скопировать

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

я думаю это как-то оптимизированно, что он все таки не копирует все заново

Верно.

Копируется только очень небольшой кусочек данных.

но там можно мутировать же

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

Копируется только очень небольшой кусочек данных.

а где можно почитать про внутренний механизм работы с объектами ?

а где можно почитать про внутренний механизм работы с объектами ?

Не используй объекты.

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

ну как бы да, мы ж обращаемся не на прямую к стору а через прокси

а где можно почитать про внутренний механизм работы с объектами ?

Нужен массив - используй иммутабельный массив. Нужно дерево, используй дерево. Забудь про объекты.

Нужен массив - используй иммутабельный массив. Нужно дерево, используй дерево. Забудь про объекты.

везде таскать за собой иммутабл ?

ну как бы да, мы ж обращаемся не на прямую к стору а через прокси

например в vue похожий механизм сделанный на геттерах/сеттерах, можно было тоже самое добавить и в react и вместо setState использовать this.state.myVariable = 2, что ИМХО не является мутацией оригинальных данных, а просто надстройка или синтаксический сахар.

но коннечно иммутабл Map не хватает почти в каждом проекте

везде таскать за собой иммутабл ?

Если тебя устраивает эта библиотека.

везде таскать за собой иммутабл ?

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

например в vue похожий механизм сделанный на геттерах/сеттерах, можно было тоже самое добавить и в react и вместо setState использовать this.state.myVariable = 2, что ИМХО не является мутацией оригинальных данных, а просто надстройка или синтаксический сахар.

Не нужно, всё равно setState понадобится.

например в vue похожий механизм сделанный на геттерах/сеттерах, можно было тоже самое добавить и в react и вместо setState использовать this.state.myVariable = 2, что ИМХО не является мутацией оригинальных данных, а просто надстройка или синтаксический сахар.

this.setState декларативно

Поэтому лучше не создавать лишних абстракций.

this.setState декларативно

this.setState позволяет коллбек прокинуть.

Не нужно, всё равно setState понадобится.

state = { set myVariable = value => { this.setState({ myVariable: value }) } }

state = { set myVariable = value => { this.setState({ myVariable: value }) } }

пиздец…

я бы за такую хуйню руки отрубал…

state = { set myVariable = value => { this.setState({ myVariable: value }) } }

Прекрасно, а теперь вариант, когда у тебя есть зависимость от стейта или пропсов.

Да плюс

я бы за такую хуйню руки отрубал…

это в виде гипотетического наброска иллюстрирующего синтаксический сахар

это в виде гипотетического наброска иллюстрирующего синтаксический сахар

Что ты будешь делать с колбеком?

например в vue похожий механизм сделанный на геттерах/сеттерах, можно было тоже самое добавить и в react и вместо setState использовать this.state.myVariable = 2, что ИМХО не является мутацией оригинальных данных, а просто надстройка или синтаксический сахар.

this.state.myVariable = 2 Но это и есть мутация

Или ты предлагаешь усложнить апи?

я бы за такую хуйню руки отрубал…

Прям как за кражу золота

Пока в JS нельзя сделать красивые и короткие(это важно) геттеры-сеттеры и полностью заприваченные переменные, будем теребить setState

Что ты будешь делать с колбеком?

это не хорошее решение, это просто пример. просто хотел показать, что думая что ты мутируешь исходный объект, ты на самом деле работаешь с механизмом, который допустим может использовать Immutable для операций с данными.

Пока в JS нельзя сделать красивые и короткие(это важно) геттеры-сеттеры и полностью заприваченные переменные, будем теребить setState

setState не просто сеттер

setState не просто сеттер

Да, знаю, он мержит, по-правильному говоря

логика обновлени стейта чуть более сложная

еще и собирает апдейты в банчи

this.state.myVariable = 2 Но это и есть мутация

это выглядит как мутация, по факту работает setState (через сеттер), который мерджит объекты.

если их много сразу

кроче не каждый setState вызовет ререндер

если их много сразу

столбики

ERROR: S client not available

логика обновлени стейта чуть более сложная

Если представить, что в ЖС есть ява/си-подобные приватные переменные и геттеры-сеттеры, то я механику представил бы так: У компонента есть открытый рендер-метод, который при вызове возвращает html-подобный код, попутно вызывая рендеры и своих детишек. При изменении приватной переменной, рендер запускается заново. Получить приватную переменную можно всегда и везде геттером. Но, в данный момент, без адовых костылей такого не будет, поэтому setState. И, само собой, грамотно мержить состояния и рендерить не весь блок тоже нужно, но оно уже есть.

Пока в JS нельзя сделать красивые и короткие(это важно) геттеры-сеттеры и полностью заприваченные переменные, будем теребить setState

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

Если представить, что в ЖС есть ява/си-подобные приватные переменные и геттеры-сеттеры, то я механику представил бы так: У компонента есть открытый рендер-метод, который при вызове возвращает html-подобный код, попутно вызывая рендеры и своих детишек. При изменении приватной переменной, рендер запускается заново. Получить приватную переменную можно всегда и везде геттером. Но, в данный момент, без адовых костылей такого не будет, поэтому setState. И, само собой, грамотно мержить состояния и рендерить не весь блок тоже нужно, но оно уже есть.

геттеры сеттеры в стиле жс это бредятина

это выглядит как мутация, по факту работает setState (через сеттер), который мерджит объекты.

И триггерит цепную реакцию переворачивания фишек в алгоритме мобикса

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

это те которые через # или TS ?

геттеры сеттеры в стиле жс это бредятина

А есть в другом стиле где-то?

это те которые через # или TS ?

#

это те которые через # или TS ?

те которые в тс не существуют в жс

А есть в другом стиле где-то?

во всех остальных языках

И триггерит цепную реакцию переворачивания фишек в алгоритме мобикса

да, там помоему все на этом и построено.

да, там помоему все на этом и построено.

Увы

во всех остальных языках

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

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

бляя там методы здесь геттеры some.setValue(value) vs some.value = value

бляя там методы здесь геттеры some.setValue(value) vs some.value = value

c#

c#

а, точно. Забыл этот говноязык

Сильно)

Пасибки :D

/me закрыл райдер.

Ничего не имею против ноты до диез

адовая конструкция эти геттеры. особенно в mobx…

адовая конструкция эти геттеры. особенно в mobx…

Просто js - это динамика, вот и все проблемы.

А в шарпе ты без IDE не выживешь, поэтому и проблем нет.

А в шарпе ты без IDE не выживешь, поэтому и проблем нет.

что тоже не говорит в пользу языка (в плюсах даже с IDE очень сложно жить)

что тоже не говорит в пользу языка (в плюсах даже с IDE очень сложно жить)

Сегодня язык - это синтаксис + тулинг.

Сегодня язык - это синтаксис + тулинг.

язык - синтаксис + тулинг = ? шта?

Сегодня язык - это синтаксис + тулинг.

а блядь ты тире не поставил

kek

походу блокнот ты юзаешь или vs code, тем язык лучше

походу блокнот ты юзаешь или vs code, тем язык лучше

А вот это реально распарсить проблема.

если код на языке легко понимать без IDE, это хороший язык

где урна для js?