🚀🚀
основную часть тела функции занимает чтение известных эффектору полей, то есть можно бросать в вызовы любые конфиги, на выходе всегда будет плоский объект с известным заранее перечнем полей
Size: a a a
2020 June 13
🚀🚀
связано это с тем, что программные методы могут вкладывать результаты работы друг друга (они же не могут знать ни типы ни значения аргументов в коде, только синтаксис)
🚀🚀
воот, а с методами, которые принимают больше одного аргумента проблема в том, как преобразовать массивы в значения полей конфига) решения пока нет, и из-за отсутствия этого, ручная обработка занимает около 20% размера библиотеки
c
воот, а с методами, которые принимают больше одного аргумента проблема в том, как преобразовать массивы в значения полей конфига) решения пока нет, и из-за отсутствия этого, ручная обработка занимает около 20% размера библиотеки
воу, удивительно
🚀🚀
казалось бы, нормализация конфига, что здесь могло бы пойти не так? 😄
c
то, что положено в поле config будет прочитано раньше всего остального тела конфига, то, что положено в поле ɔ — позже всех, то есть это можно представить как
а так как в поле ɔ кладутся аргументы из исходного кода, то они всегда перезаписывают программные значения, к примеру в кейсе с явным name
return {
...part.config,
...part,
...part.ɔ
}а так как в поле ɔ кладутся аргументы из исходного кода, то они всегда перезаписывают программные значения, к примеру в кейсе с явным name
теперь я примерно понимаю как это работает
🚀🚀
вообще, алгоритм выше можно упростить в паре мест, но к сожалению с проблемой парсинга массивов они не связаны 😒
c
сейчас у меня всего два юнита внутри throttle
так, чтобы корректно заработало, мне нужно рекурсивно вытащить name и прокинуть в эффект и ивент
тоже самое с loc
а как с sid правильно поступить?
так, чтобы корректно заработало, мне нужно рекурсивно вытащить name и прокинуть в эффект и ивент
тоже самое с loc
а как с sid правильно поступить?
TG
многие состояния лучше делать чисто вычисляемыми через map и combine, чем пытаться подключать через сэмпл
обрати внимание на оставшийся сэмпл, он с таргетом — когда у сущности, созданной через сэмпл есть только одно применение, то это значит, что лучше использовать target вместо неё)
https://codesandbox.io/s/modest-thompson-gu2io?file=/src/App.js
обрати внимание на оставшийся сэмпл, он с таргетом — когда у сущности, созданной через сэмпл есть только одно применение, то это значит, что лучше использовать target вместо неё)
https://codesandbox.io/s/modest-thompson-gu2io?file=/src/App.js
а вот вчера как раз с кем-то и говорили как лучше) меня убеждали что лучше создать event через sample и его уже заюзать. но мне с target нравиться больше
TG
а вот снапшот формы оказался слишком самостятельным для того, чтобы быть вычисляемым или сэмплированным, его оказалось оптимальнее вынести в стор явно
но насчет снапшота не понял, что имеется ввиду под снапшотом
🚀🚀
но насчет снапшота не понял, что имеется ввиду под снапшотом
то, с чем сравнивают текущее состояние формы, чтобы понять, было ли оно изменено или нет. в коде были признаки того, что управление этим "тем, с чем сравнивают" достаточно сложное для того, чтобы быть отдельным стором. на отдельный стор и reset проще повесить и вообще легче воспринимать
🚀🚀
сейчас у меня всего два юнита внутри throttle
так, чтобы корректно заработало, мне нужно рекурсивно вытащить name и прокинуть в эффект и ивент
тоже самое с loc
а как с sid правильно поступить?
так, чтобы корректно заработало, мне нужно рекурсивно вытащить name и прокинуть в эффект и ивент
тоже самое с loc
а как с sid правильно поступить?
извлекать данные из source до валидации не стоит, будет падать в аргументах функции
🚀🚀
можно применять конфиг по образцу стора, в createStore первый аргумент никак не меняется плагином, а все конфиги накидываются во второй. если есть второй аргумент — значит это данные, добавленные бабель-плагином
c
можно применять конфиг по образцу стора, в createStore первый аргумент никак не меняется плагином, а все конфиги накидываются во второй. если есть второй аргумент — значит это данные, добавленные бабель-плагином
вот это интересный кейс
c
а как бабель плагин определяет где какой вариант метода?
🚀🚀
никак, createStore всегда обработан только второй аргумент
🚀🚀
но вообще говоря, проще парсить рекурсивно, потому что массивы в аргументах всплывают именно после добавления второго)
c
никак, createStore всегда обработан только второй аргумент
ну тогда лучше не добавлять сложности
c
тем более в стороннее решение
c
все таки не очень хочу городить кастомный парсинг в библиотеке