generic message display controlled by reducer logic

[richardiphillips]

No description provided.

[lewisrenfrew]

cool - I had debated extending the reducer out to support managing state that isn't directly part of the req

I guess this just means that when formState gets submitted via a request (on save click) it might include some extra data like formState.message that the server will just ignore when it binds the request body to a RequisitionHeaderResource

[richardiphillips]

cool - I had debated extending the reducer out to support managing state that isn't directly part of the req

I guess this just means that when formState gets submitted via a request (on save click) it might include some extra data like formState.message that the server will just ignore when it binds the request body to a RequisitionHeaderResource

Yeah. I ummed and aahhed about it. Feels the lesser of two evils to keep all the logic inside the reducer but like everything else it can always be changed

[lewisrenfrew]

cool - I had debated extending the reducer out to support managing state that isn't directly part of the req
I guess this just means that when formState gets submitted via a request (on save click) it might include some extra data like formState.message that the server will just ignore when it binds the request body to a RequisitionHeaderResource

Yeah. I ummed and aahhed about it. Feels the lesser of two evils to keep all the logic inside the reducer but like everything else it can always be changed

One very simple similar idea i had was extend the formState object

{
req: {... all the req stuff},
messages: [] // some messages, could even include validation results etc,
anythingElse: any other state we might want to manage that isnt directly part of the req data structure
}

and then only submit formState.req in requests on save clicks etc

[richardiphillips]

cool - I had debated extending the reducer out to support managing state that isn't directly part of the req
I guess this just means that when formState gets submitted via a request (on save click) it might include some extra data like formState.message that the server will just ignore when it binds the request body to a RequisitionHeaderResource

Yeah. I ummed and aahhed about it. Feels the lesser of two evils to keep all the logic inside the reducer but like everything else it can always be changed

One very simple similar idea i had was extend the formState object

{ req: {... all the req stuff}, messages: [] // some messages, could even include validation results etc, anythingElse: any other state we might want to manage that isnt directly part of the req data structure }

and then only submit formState.req in requests on save clicks etc

100%. that's actually how i had it sketched out in my notepad but sort of forgot while i was messing about. i'll refactor next time i'm in