I would say that the objects you are getting are not well designed.
If you need to check that often that it will be a problem.
I mean you can overdo everything, adding 200 npm packages even if they just do small things would also be a bad pattern. In the end, it is in your fingertips to decide.
Right, yep - if you're constantly checking the same thing for null or not, then maybe you need to abstract that to give you a better framework/way to access it.
Not only are you doing extra branching, but by having defaults at the usage site instead of defaults site you could have inconsistencies.
Instead, on construction of the this, you could have
this.data=_.merge(defaultData,incomingData)
and then access all the properties unconditionally.
(You could also only merge in properties that already exist in defaultData tree, and perform validation at this stage, creating a very predictable this)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would say that the objects you are getting are not well designed.
If you need to check that often that it will be a problem.
I mean you can overdo everything, adding 200 npm packages even if they just do small things would also be a bad pattern. In the end, it is in your fingertips to decide.
Right, yep - if you're constantly checking the same thing for null or not, then maybe you need to abstract that to give you a better framework/way to access it.
Like always thinking is the key here 😉
IMO it lends itself to patterns like:
Not only are you doing extra branching, but by having defaults at the usage site instead of defaults site you could have inconsistencies.
Instead, on construction of the
this
, you could haveand then access all the properties unconditionally.
(You could also only merge in properties that already exist in
defaultData
tree, and perform validation at this stage, creating a very predictablethis
)