Data can come from a variety of sources - a form, query parameters, an external file - and data from each source needs to be validated before it can be used. A change-set provides a place to put data for validation before it is written to the @tracked properties that drive its use by the rest of the application.
I am running into two design problems for entry of numeric data.
First, validation must necessary have two tiers. In the first tier, “can the entered data be parsed into numbers?”. In the second tier lie all the questions about the numeric value in isolation and then about the value’s consistency with the rest of the data. You can’t really ask any of the other questions until you have verified that what was provided parses correctly. Fleshing this out a little, the same piece of data from different sources may have different text formats, but once it is reduced to a number, the rest of the validation is about the nature of the data rather than its representation and can generally be common.
Right now, using the ember-changeset proxy for the validation of the parsed data means both sides must be numbers, which leaves the problem of cobbling a second tier of text entry validation on top of it and keeping local data for the field text, so that validation failures don’t just overwrite the data the user typed with what’s in the changeset. The user wants to be able to correct what was typed rather than losing it.
Second, it seems to me a changeset should encompass only the set of data being delivered from a single source, since a changeset validates if the data is consistent with its companions before any of them are permitted to pass into the @tracked storage. Therefore, I would want one changeset for an input form, another for the data coming from a file, and a third for changes to the query parameters. Each of them, upon save(), delivers data to the single set of @tracked data they all protect.
Design problem: What happens to the data in one changeset when a save() from another changeset changes the underlying @tracked data? Does it ignore the change? Is there a notification so the app can decide what to do about the pending values that haven’t been passed to save() yet?
Combine those two design problems, and we are finding it difficult to use pure “business as usual” DDAU to have changes to the @tracked data flow through the changesets to the text fields when the tracked data is reloaded outside the context of the form’s changeset. We’re trying to avoid sledge hammers like reloading routes or shoehorns like {{on-update}} and want to rely solely on the natural flow of tracked architecture. We’re even wondering whether we need our own hybrid text-entry/numeric-validation changeset implementation to support all this, but don’t really want to go there.
Any guidelines on how to proceed? Is there something obvious we’re doing wrong?
1 post - 1 participant