jgaehring
commented
4 years ago Right now our components are littered with null checks, in a haphazard attempt to defend against potential null and undefined values.
This happens in the template itself:
and in computed values:
Yet we're still getting reports from users who get into a broken state, where the screen goes blank and they can no longer use the app. So this is clearly not covering all our bases, and it's a major problem that needs to be addressed (before 1.0.0, I believe, so I'm adding this to that milestone).
I think there are two possible ways to remedy this.
The first is to clean up nullish values right before they get passed down to the field modules as props. We're already doing some processing to remove metadata before passing them down, so this could just be included as part of that process:
The second possibility, and this seems like the most comprehensive way to approach this, would be to go right to the source, and guarantee that when all logs are created and updated, they receive only valid property values. This means going into farmLog and replacing the default_value's, which are crap, with more reliable default values. We had something like this in the old makeLog implementation, but we had to hard code a lot of default values by hand, which won't suffice now that we're supporting all logs the server supports, and won't know what those are until runtime. Instead we can generate our own defaults based on the each field's type, such as entityreference, text_long, taxonomy_term_reference, etc. Ideally, we would could get this type data from /farm.json, but I think for now it should be easy enough to provide a simple lookup table, something like:
const fieldDefaults = {
entityreference: [],
text_long: '',
taxonomy_term_reference: [],
// etc
}Then instead of this:
we could do something like this:
const entries = Object.entries(schema).map(([key, { type: fieldType }]) => {
const data = props[key] || fieldDefaults[fieldType];
return [key, { changed, data, conflicts: [] }];
});
mstenta
tool172
Starting this issue after discussion with @jgaehring in the farmOS dev call 5/12/20.