No, I don't think it's always "bad". (Apart from that I dislike the non-specificity of "bad"). Sometimes choosing tight coupling makes sense. An example is that I think tight coupling from a module to a domain-specifc data structure is often 'fine' in that it doesn't increase complexity. Dave Farley calls this "the right amount of coupling / reasonable coupling" I believe.
11:30 If you had a function where the point was to return a unique list of items... Why not just return a set? That would be even simpler, and way more explicit. I like this example, but in my experience, the biggest contributor to complexity is just getting into the mess in the first place... If you are collecting a list of unique items, why not just use a set from the start... I get this is besides the point of the video, but I couldnt resist commenting on it
@@branvandermeer we defenetly do. But I think it would be better to just return the Set(if you imagine this as a function) dont convert it to a Set then an array again.
I understand your example was spesifically for stripping out duplicates in an array, my original comment was trying to point out that alot of times the need for this could have been avoided all together and thus reduced the complexity even more
10:19 Not a fan of the Boolean(meta), there is just so mush javascript weirdness... Also what happens if the newPayload is a boolean with the value false Would much rather have something like this... and if you really had to strip away the undefined and nulls just create a function for it. const getAction = (newPayload, isRejected) => { return { type: `${type}_${isRejected ? REJECTED : FULFILLED}` error: isRejected, meta : meta, payload: newPayload, } }
The original code is using `!!x`. I instead prefer the readability of `Boolean(x)`. But it seems you're right, it's unnessesary if I look at the ESLint rule no-extra-boolean-cast: eslint.org/docs/latest/rules/no-extra-boolean-cast#rule-details The point of this video is to show that syntax like ternary/conditional operators are just harder to read, inrrespectively of your seniority. I do think your code works as well for that purpose! 👍🏻
The regular code zen. 😊 Just in time for the new year! 🎉 Thanks Bran!
Thank you!
You're welcome! If I way ask: what parts of the video were easy for you (if any), and what parts were hard? Is it easy to put into practice?
Thanks a lot...
Do you think that high copeling is always a bad thing? I'm not sure if it is synonymous with complexity. Maybe if you say copeling between modules
No, I don't think it's always "bad". (Apart from that I dislike the non-specificity of "bad"). Sometimes choosing tight coupling makes sense. An example is that I think tight coupling from a module to a domain-specifc data structure is often 'fine' in that it doesn't increase complexity. Dave Farley calls this "the right amount of coupling / reasonable coupling" I believe.
@@branvandermeer Thanks for the answer. Like your videos, keep em coming :D
11:30 If you had a function where the point was to return a unique list of items... Why not just return a set? That would be even simpler, and way more explicit. I like this example, but in my experience, the biggest contributor to complexity is just getting into the mess in the first place... If you are collecting a list of unique items, why not just use a set from the start... I get this is besides the point of the video, but I couldnt resist commenting on it
I don't understand your point, I am recommending to use Set at 11:40, right? I think we agree :)
@@branvandermeer we defenetly do. But I think it would be better to just return the Set(if you imagine this as a function) dont convert it to a Set then an array again.
I understand your example was spesifically for stripping out duplicates in an array, my original comment was trying to point out that alot of times the need for this could have been avoided all together and thus reduced the complexity even more
10:19 Not a fan of the Boolean(meta), there is just so mush javascript weirdness... Also what happens if the newPayload is a boolean with the value false
Would much rather have something like this... and if you really had to strip away the undefined and nulls just create a function for it.
const getAction = (newPayload, isRejected) => {
return {
type: `${type}_${isRejected ? REJECTED : FULFILLED}`
error: isRejected,
meta : meta,
payload: newPayload,
}
}
The original code is using `!!x`. I instead prefer the readability of `Boolean(x)`. But it seems you're right, it's unnessesary if I look at the ESLint rule no-extra-boolean-cast: eslint.org/docs/latest/rules/no-extra-boolean-cast#rule-details
The point of this video is to show that syntax like ternary/conditional operators are just harder to read, inrrespectively of your seniority. I do think your code works as well for that purpose! 👍🏻