-
Notifications
You must be signed in to change notification settings - Fork 136
path-reducer #329
Comments
Hi @miqmago, Personally I like to decouple actions from state changes. Actions should just describe what happened, not what to do. So instead of: const action = {
type: 'updateElementInObject',
meta: ['bar', 'boo'],
payload: {
boo: 1
}
}; I'd choose something like: const action = {
type: 'update_requested',
payload: {
boo: 1
}
}; This comment of @slorber (as lot of other comments of the same author) explains perfectly my thoughts: reduxjs/redux#1528 (comment) |
Thanks. In that case, maybe there is a better option for this problem. I'm sorry for extending so much, but the problem is not easy and I very much appreciate your help: I've got an structure with about +150 nested types ( PartiesType.js import t from 'tcomb-form-native';
import { getBusinessType, getBusinessTypeOptions } from './BusinessType';
export function getPartiesType(options) {
const PartiesTypeBase = {
SellerParty: getBusinessType(options),
BuyerParty: getBusinessType(options),
};
return t.struct(PartiesTypeBase);
}
export function getPartiesTypeOptions(options) {
return { fields: {} };
} BusinessType.js import t from 'tcomb-form-native';
import {
getAdministrativeCentresType,
getAdministrativeCentresTypeOptions,
getIndividualType,
getIndividualTypeOptions,
getLegalEntityType,
getLegalEntityTypeOptions,
getPartyIdentificationType,
getPartyIdentificationTypeOptions,
getTaxIdentificationType,
getTaxIdentificationTypeOptions,
} from '../reused-simple-enums';
export function getBusinessType(options) {
const { personTypeCode = 'I' } = options;
const BusinessTypeBase = {
TaxIdentification: getTaxIdentificationType(options),
PartyIdentification: getPartyIdentificationType(options),
AdministrativeCentres: getAdministrativeCentresType(options),
Individual: {},
LegalEntity: {},
};
if (personTypeCode === 'J') {
BusinessTypeBase.LegalEntity = getLegalEntityType(options);
delete BusinessTypeBase.Individual;
} else { // 'I' per defecte
BusinessTypeBase.Individual = getIndividualType(options);
delete BusinessTypeBase.LegalEntity;
}
return t.struct(BusinessTypeBase);
}
export function getBusinessTypeOptions(options) {
return {
auto: 'placeholders',
fields: {
TaxIdentification: getTaxIdentificationTypeOptions(options),
PartyIdentification: getPartyIdentificationTypeOptions(options),
AdministrativeCentres: getAdministrativeCentresTypeOptions(options),
Individual: getIndividualTypeOptions(options),
LegalEntity: getLegalEntityTypeOptions(options),
},
};
} And so on. This structure makes easy to create the corresponding
Does that mean that every change in a action = {
type: 'update/Parties/SellerParty/TaxIdentification/PersonTypeCode',
payload: {
PersonTypeCode: 'J'
}
}; Anyway this is a different way to let the action know what it has to be done. The difference is that it's difficult to operate with action = {
type: 'updateEInvoice',
meta: ['Parties', 'SellerParty', 'TaxIdentification', 'PersontTypeCode'],
payload: {
PersonTypeCode: 'J'
} Ths action is very easy to construct with the Also does it mean that the whole structure should be duplicated with reducer functions, mapping the state? I personally think that it makes hard to maintain: every change made in This was the motivation when writting |
I see, makes sense. So it's a matter of taste I guess. I just prefer: const action = {
type: 'form_changed',
payload: {
what: ['bar', 'boo']
value: 1
}
} but the result will be the same as yours. Maybe I just can't see the use case and it's a dumb question, but out of curiosity, why are you interesting in such granular updates rather than storing the whole form value? const action = {
type: 'form_changed',
payload: {
...whole form value here...
}
} Also, values coming from the |
I like your proposal, I will try to update the plugin. It makes sense to keep all data in payload and maybe it's better for action validation purposes. I'm interested in granular updates as the The problem here is that due it is a big form, I had to split it in small forms that are being filled each one in a tab screen. The whole form is not submitted until all the screens are filled in. I still haven't dedicated enought time to think deep about the validation problem... |
Closing for inactivity |
I've developed this path-reducer which makes easy to save the form values inside redux state.
Please, let me know your opinion. Also some examples on how to implement it with
tcomb-form
andtcomb-form-native
are coming in the future.The text was updated successfully, but these errors were encountered: