m
почему нельзя в одно соединить?
Size: a a a
2020 September 24
🚀🚀
не не не, никаких аккуратно
а то потом «ой, а куда третий аргумент в event.create делся 8 месяцев назад»
c
почему нельзя в одно соединить?
можно) это следующий уровень шортхендов
m
принято
КН
я тут подумал, у map же нет обратной связи, если я изменяю мапнутый стор — оригинальный об этом не знает.
а можно сделать что-то типа стора-линзы? изменение которого будет изменять оригинальный стор.
хотя для этого уже нужно будет в структуру данных стора лезть…
а можно сделать что-то типа стора-линзы? изменение которого будет изменять оригинальный стор.
хотя для этого уже нужно будет в структуру данных стора лезть…
Это похоже на миграции в БД. Тебе придётся описывать и обратную трансформацию, которая не всегда возможна. И это уже не map.
c
persistFields(store, {
save: {
myFoo: ‘foo’,
bar: 'bar’,
},
load: {
myFoo: ‘foo’,
bar: ‘bar’,
}
})И сразу же делаем шортхенд
хотя я бы делал так:
получается короче и более расширяемо
persistFields(store, {
myFoo: ‘foo’,
bar: { save: ‘boo’, load: ‘boo’ },
baz: {
save: ({ name }) => baz.toString(32),
load: (state, value) => ({ ...state, name: parseInt(value, 32) }),
},
})получается короче и более расширяемо
КН
я тут подумал, у map же нет обратной связи, если я изменяю мапнутый стор — оригинальный об этом не знает.
а можно сделать что-то типа стора-линзы? изменение которого будет изменять оригинальный стор.
хотя для этого уже нужно будет в структуру данных стора лезть…
а можно сделать что-то типа стора-линзы? изменение которого будет изменять оригинальный стор.
хотя для этого уже нужно будет в структуру данных стора лезть…
A + B = C
Допустим, A, B, C — инпуты. Если менять значения A или B, то это одна логика. Если — C, — другая. Может показаться, что это твой кейс. Но нет. Намного прозрачнее просто взять и описать то, как то или иное событие влияет на все сторы.
Допустим, A, B, C — инпуты. Если менять значения A или B, то это одна логика. Если — C, — другая. Может показаться, что это твой кейс. Но нет. Намного прозрачнее просто взять и описать то, как то или иное событие влияет на все сторы.
🚀🚀
хотя я бы делал так:
получается короче и более расширяемо
persistFields(store, {
myFoo: ‘foo’,
bar: { save: ‘boo’, load: ‘boo’ },
baz: {
save: ({ name }) => baz.toString(32),
load: (state, value) => ({ ...state, name: parseInt(value, 32) }),
},
})получается короче и более расширяемо
bar сохраняется в одно поле а загружается в другое 😳😳🤯
yv
мне только кажется, что несколько маленьких сторов + комбайн будет и понятнее, и удобнее 🙂
c
bar сохраняется в одно поле а загружается в другое 😳😳🤯
разве?) или это ты из-за кавычек?)
🚀🚀
ну это единственное отличие варианта в bar от той что в myFoo
c
ну это единственное отличие варианта в bar от той что в myFoo
ну по факту, вариант { save: string, load: string } даже не нужен
ибо логически его нельзя обосновать
ибо логически его нельзя обосновать
🚀🚀
ага
🚀🚀
короче шортхэнд может быть только вида
storageField: 'store field'c
останется только:
один сохраняет в одно и тоже поле
а другой позволяет преобразовывать
полезно для даты например
persistFields(store, {
myFoo: ‘foo’,
baz: {
save: ({ name }) => baz.toString(32),
load: (state, value) => ({ ...state, name: parseInt(value, 32) }),
},
})один сохраняет в одно и тоже поле
а другой позволяет преобразовывать
полезно для даты например
persistFields(store, {
when: {
save: ({ when }) => when.toISOString(),
load: (state, value) => ({ ...state, when: new Date(value) }),
},
})yv
A + B = C
Допустим, A, B, C — инпуты. Если менять значения A или B, то это одна логика. Если — C, — другая. Может показаться, что это твой кейс. Но нет. Намного прозрачнее просто взять и описать то, как то или иное событие влияет на все сторы.
Допустим, A, B, C — инпуты. Если менять значения A или B, то это одна логика. Если — C, — другая. Может показаться, что это твой кейс. Но нет. Намного прозрачнее просто взять и описать то, как то или иное событие влияет на все сторы.
я не очень в фп и терминологии, но линза вроде применяется только к структуре, и позволяет менять часть именно структуры.
A = { a: 1, b: 2 }
A” = lens(A, [‘a’])
A”.a = 2
// A == { a: 2, b: 2}🚀🚀
останется только:
один сохраняет в одно и тоже поле
а другой позволяет преобразовывать
полезно для даты например
persistFields(store, {
myFoo: ‘foo’,
baz: {
save: ({ name }) => baz.toString(32),
load: (state, value) => ({ ...state, name: parseInt(value, 32) }),
},
})один сохраняет в одно и тоже поле
а другой позволяет преобразовывать
полезно для даты например
persistFields(store, {
when: {
save: ({ when }) => when.toISOString(),
load: (state, value) => ({ ...state, when: new Date(value) }),
},
})во, так норм 👍
🚀🚀
я тут подумал, у map же нет обратной связи, если я изменяю мапнутый стор — оригинальный об этом не знает.
а можно сделать что-то типа стора-линзы? изменение которого будет изменять оригинальный стор.
хотя для этого уже нужно будет в структуру данных стора лезть…
а можно сделать что-то типа стора-линзы? изменение которого будет изменять оригинальный стор.
хотя для этого уже нужно будет в структуру данных стора лезть…
о, кстати
🚀🚀
я вспомнил, этот кейс существует в реальности
🚀🚀
undo/redo