O
Мне честно говоря пофигу, как оно реализовано в языке. Но вот в джаве почему-то люди не используют такие конструкции в основном
в жаве вроде как и нет никакого аналога do-нотации
Size: a a a
2020 November 05
MB
в жаве вроде как и нет никакого аналога do-нотации
Ну сделать проверку на нил чейнингом я думаю нет никакой проблемы
AL
Меня больше интересует, как именно функциональный компонент получает информацию о состоянии при помощи хуков. До введения хуков - считалось, что поскольку у функциональных компонентов нет backing instance (переводится в российской литературе как "экземпляр поддержки", хранящего состояние компонента), то у него нет, как состояния, так и всех сущностей, связанных с жизненным циклом. Есть теория, что поскольку в любом случае есть компонент root, который вроде как классовый, то хук есть ни что иное как средство работы с состоянием экземпляра поддержки корневого классового компонента. Т.е. можно предположить, что хук есть:
а) в целом схожая по задумке с Redux штука (ограничение мест хранения состояния)
б) коррелирует с идеями, выраженными в Haskell - если работаешь с нечистыми функциями (побочные эффекты, состояние и т.д.), будь добр это делать в отдельном месте, в React - операции с пропсами должны быть написаны на pure functions
а) в целом схожая по задумке с Redux штука (ограничение мест хранения состояния)
б) коррелирует с идеями, выраженными в Haskell - если работаешь с нечистыми функциями (побочные эффекты, состояние и т.д.), будь добр это делать в отдельном месте, в React - операции с пропсами должны быть написаны на pure functions
До введения хуков в функциональных компонентах не было стейта
MB
Или каким-то другим способом, чтобы не наплодить объектов
MB
А, ну есть Optional, но там кажется апи какое-то паленое немного и никто все равно не использует
MB
Вот кстати еще один хороший пример, когда апи сделано без "теоретизирования": интерфейс Future
O
Ну сделать проверку на нил чейнингом я думаю нет никакой проблемы
там возникают две разные проблемы: если строишь цепочку Map(..).FlatMap(..), то это субоптимально, т.к. все функции выполнятся даже если optional изначально был none; если же использовать .FlatMap(.. => ...FlatMap(.. => ...FlatMap(..))), то получается лучше, но скобок очень много
ST
ну, в терминологии теории категорий точно глупость не скажут 😊
в общем, кмк, с людьми надо разговаривать на понятном с ними языке, поэтому избегать непонятных большинству кложуристов терминов в чатике 😊
ST
Вот кстати еще один хороший пример, когда апи сделано без "теоретизирования": интерфейс Future
в каком языке?
AC
Мне честно говоря пофигу, как оно реализовано в языке. Но вот в джаве почему-то люди не используют такие конструкции в основном
В джаве много чего не используют и используют много такого что очень устарело
O
во втором случае проблема не только в скобках, но и в квадратичном времени исполнения для некоторых монад, например free
MB
там возникают две разные проблемы: если строишь цепочку Map(..).FlatMap(..), то это субоптимально, т.к. все функции выполнятся даже если optional изначально был none; если же использовать .FlatMap(.. => ...FlatMap(.. => ...FlatMap(..))), то получается лучше, но скобок очень много
да в качестве хака зашло бы даже написать оверлоады
maybeChain<I,T1,T2>(Optional<I> initialValue, Function<I, Optional<T1>> firstMapping, Function<T1, Optional<T2>> secondMapping) и тд
maybeChain<I,T1,T2>(Optional<I> initialValue, Function<I, Optional<T1>> firstMapping, Function<T1, Optional<T2>> secondMapping) и тд
E
До введения хуков в функциональных компонентах не было стейта
Так вот мой подкапотный вопрос был связан как раз с тем, как именно он этот стейт получает:
1) из экземпляра поддержки родительского классового компонента (концептуально - оно логичнее)
2) имеет свой собственный экземпляр поддержки (в лоб)
1) из экземпляра поддержки родительского классового компонента (концептуально - оно логичнее)
2) имеет свой собственный экземпляр поддержки (в лоб)
AC
Меня больше интересует, как именно функциональный компонент получает информацию о состоянии при помощи хуков. До введения хуков - считалось, что поскольку у функциональных компонентов нет backing instance (переводится в российской литературе как "экземпляр поддержки", хранящего состояние компонента), то у него нет, как состояния, так и всех сущностей, связанных с жизненным циклом. Есть теория, что поскольку в любом случае есть компонент root, который вроде как классовый, то хук есть ни что иное как средство работы с состоянием экземпляра поддержки корневого классового компонента. Т.е. можно предположить, что хук есть:
а) в целом схожая по задумке с Redux штука (ограничение мест хранения состояния)
б) коррелирует с идеями, выраженными в Haskell - если работаешь с нечистыми функциями (побочные эффекты, состояние и т.д.), будь добр это делать в отдельном месте, в React - операции с пропсами должны быть написаны на pure functions
а) в целом схожая по задумке с Redux штука (ограничение мест хранения состояния)
б) коррелирует с идеями, выраженными в Haskell - если работаешь с нечистыми функциями (побочные эффекты, состояние и т.д.), будь добр это делать в отдельном месте, в React - операции с пропсами должны быть написаны на pure functions
По сути хуки это и есть централизованное хранилище с довольно странным алгоритмом извлечения
AC
Это отчасти обусловлено особенностями джаваскрипта
MB
в каком языке?
В джаве
MB
во втором случае проблема не только в скобках, но и в квадратичном времени исполнения для некоторых монад, например free
Да ладно вам монады переносить в джаву как есть, бытовые проблемы бы там решить
VL
я про хук думал как просто про замыкание с сахаром синтаксическим
ST
и какую теоретическую базу можно подвести к этому интерфейсу?
O
да в качестве хака зашло бы даже написать оверлоады
maybeChain<I,T1,T2>(Optional<I> initialValue, Function<I, Optional<T1>> firstMapping, Function<T1, Optional<T2>> secondMapping) и тд
maybeChain<I,T1,T2>(Optional<I> initialValue, Function<I, Optional<T1>> firstMapping, Function<T1, Optional<T2>> secondMapping) и тд
тут возникает проблема недоступности старых значений. напр.
ma.FlatMap(a => mf(a).FlatMap(fa => mg(a + fa))) не сделать