I think it can if you overdo it, yes (there are a few blogposts about that if you search for them) - but in general, for patterns like checking if a prop exists, etc, I think it's a good thing.
There might be an argument for: "if you need to do that regularly, then maybe you need a different abstraction or way of doing things"... but I haven't thought too much about that, so I'm not sure.
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.
Is there any issue in Ruby with people overusing this feature and it becoming unclear what is nullable and what isn't?
I think it can if you overdo it, yes (there are a few blogposts about that if you search for them) - but in general, for patterns like checking if a prop exists, etc, I think it's a good thing.
There might be an argument for: "if you need to do that regularly, then maybe you need a different abstraction or way of doing things"... but I haven't thought too much about that, so I'm not sure.
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
defaultDatatree, and perform validation at this stage, creating a very predictablethis)