Но линзы просто для получения данных мне кажутся бессмысленными

Для этого я использую path

https://twitter.com/GiulioCanti/status/910812294942199808

для вложенных интерфейсов тоже работает?

хз

не проверял пока

https://twitter.com/GiulioCanti/status/910812294942199808

О, наконец увидел типизированные линзы. Спасибо, ухожу от assocPath )

Но линзы просто для получения данных мне кажутся бессмысленными

Удобно если вычислять линзу и работать с ней в другом месте

Удобно если вычислять линзу и работать с ней в другом месте

Именно для этого линзы и предназначены. И именно такого юзкейса в своей работе я никогда не видел )

Вычислить можно и path

рамдовский

А R.over ?

Редюсеры одной строкой вычислять

Но линзы просто для получения данных мне кажутся бессмысленными

Когда у тебя есть getter и setter, ты можешь взять структуру, обновить вложенный в неё объект и сохранить изменения

А R.over ?

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

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

Когда у тебя есть getter и setter, ты можешь взять структуру, обновить вложенный в неё объект и сохранить изменения

Когда это может быть лучше чем evolve?

Для переиспользования

Все в рамда для переиспользования. Я могу создать функцию-evolve, и переиспользовать ее

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

Та же фигня с evolve

Как у еволва с композицией?

Не вижу ваианта сделать красиво

Как у еволва с композицией?

Нормально. Ты же прописываешь там любые функции-трансформеры. Ими могут быть и другие еволвы

evolve — это просто частный случай

Очень хорошо, что твои кейсы сводятся только к объектам, у которых обновляются просто отдельные поля

Но это только часть возможных вариантов, причём далеко не самая эффективная

Очень хорошо, что твои кейсы сводятся только к объектам, у которых обновляются просто отдельные поля

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

Обычные нормализованные данные, например

Хранить удобнее в одном формате, а использовать — в другом

Хранить удобнее в одном формате, а использовать — в другом

вполне возможно. Спасибо!

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

https://twitter.com/GiulioCanti/status/910812294942199808

Чёт упорото

Не очень функциональный стиль, мне кажется

Композицию неудобно делать будет

Это проблема всех линз через пару (get, set)

Композицию неудобно делать будет

pipe(lenses.prop.get, ...)

pipe(lenses.prop.get, ...)

Аргумент указывать придется

pipe(lenses.prop.get, ...)

Не вариант, я хочу линзу на выходе, чтобы и гет, и сет, а не геттер

А

понял

ну gcanti дичь делает

пробовал кто реализовать редакс стор через линзы а не редюсеры ?

get на экшон, set на стейт ) мерджа объект из экшена в состояние

over(getSetLens,identity, state)

типа того

на элме что-то подобное писал, там предпочитают не композицию редьюсеров, а один плоский на все экшоны на всю модель. Использовал монокль. Потом отказался

Почему отказался ? У меня тс плохо вывозит многоуровневый комбайн редьюсерс

и я сам забывал, чего там где комбайнил

потому что в элме линзы нужно вручную писать типа userLens = let get = .user set newUser m = { m | user = newUser } in lens get set

и я устал это делать. В js линзы можно генерировать, так что мб и использовал бы. В хаскеле есть makeLens, так что там это тем более имеет смысл

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

Как минимум нужны ещё призмы и профункторы

Тогда только можно будет что то делать)

ну призмы там были

вот вам часть от профунктора (контрамап) https://github.com/DrBoolean/Oh-Composable-World

Как контрвариант связан с профунктором?

кто такие призмы ?

Как минимум нужны ещё призмы и профункторы

Нашёл такую репу - https://github.com/RocketPuppy/redux-consumer-toolkit

Как контрвариант связан с профунктором?

тем что там мап и контрамап

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

призмы это такие колинзы) Линзы для сумтипов. То есть как произведение дуально к копроиизведеню (сумме), так призмы дуальны к линзам (линзы берут часть произведения, призмы ветку) https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick-of-the-week/a-little-lens-starter-tutorial

Красиво, под тс, выбери что то одно ?

Красиво, под тс, выбери что то одно ?

Что ты думаешь по поводу этого тулкита ?

const ProfunctorI: Profunctor<*, *, *, *, *>

ну он же выводит типы )

в тс надо таскать их, и будет 3-х этажная конструкция

Надо будет поближе посмотреть)

что за херня? чего 4? Functor<*, *, *, *>

в типах описано

* -> * вроде

Ну это не кайнды ?

Это existencial operator в флоу

херня какая-то

Естественно, потому что в тс такого пока что даже теоретически быть не может

при чем тут тс?

Ну у остальных такая запись вопросов не вызывает

Хотя выглядит забавно конечно

Ещё не оч понимаю зачем он всю рамду в код притащил

вероятно что-то поменял

я так понял призмы есть в монокль тс

company .compose(address) .compose(street) .compose(name) .asOptional() .compose(firstLetter) .modify(s => s.toUpperCase())(employee)

скорее всего бот

Шо за рыта?

Ладно кароче так то лодаш гавно да, все функции мутабельны с объектами связанные

const cloneArgs = R.map(clone) const promapArgs = f => (...args) => f(cloneArgs(args)) lodash = R.map(promapArgs, lodash)

=)

?

привет

neprivet.ru в био (

лол

в ноджс чате запостили походу

combot.org/chat/-1001071213089

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