A collection of Either examples compared to imperative code

Wrap has an error. Should be something like preview => { ...example, preview }, not ex => ....

Yes, wondered about that for a bit too. Although I'd describe it like this: the fold on unpacking the read 'preview' from the file should clone example and then assign the new preview prop.

.fold(() => example,
        preview => Object.assign({ preview }, example))

I would maybe even Object.assign({}, example, { preview }) to be nice and obvious.

Yep! Sorry about the mistake there. This is what I should have had

Hi,

In second example (getPrefs method), shoul we also check for existance of 'preferences' property of user object?

You totally can! We can check everything we feel like.

Hi Brian, Thanks for reponse, one question regarding 'checking' if something exist or if parameters are 'right' type or not empty, what is your approach or best practice, do you check everything for existance(or if parameters are right type or not empty)?

I think the best practice is to return Either's from low level "partial" functions that might return null. If they do that, then when you're at an application level, you've ensured existence at the edges so you don't end up with a bunch of unnecessary (paranoia-driven-development) checks in your main logic.

In parseDbUrl example, there is a small difference between the imperative code and the functional, if the c.url is falsy the imperative will return undefined and the functional will return null.

Hi Alexander, wouldn't ~~~~js preview => Object.assign({ preview }, example) ~~~~ potentially just return the original example should it already had a preview value because .assign() basically says take values from right hand side object(s) and insert it into the one(s) on the left.?

@Nik, Hello Nik, I think you're right. If example has a preview property on it, it will override the important change statement that is the preview property freshly created. I think the common use case is to put at the right side properties that we want to update in the object that is on the left, but not the contrary. But if we do like so : Object.assign(example, {preview}), then we mutate example... I think that's why Alexander wrote that it would be nice and obvious to use: Object.assign({}, example, {preview}) (But even like this, what if example had properties on its prototype chain? They will disappear ...?) Because whatever, Brian just wanted to give us some examples to understand functional way of coding.

It is being 2 days since I start that course Brian,

I think you should write those examples with ES6, Sometimes, it makes it really difficult to reason about those functions. (I get used to but I was almost quitting in your first lesson)

And Thanks, I start to look all my JS problems from a different perspective, probably after I figure out Ramda those lesson will be invaluable and I will have more fluent JS pages.

Best regards from deepCopy junky :)