A collection of Either examples compared to imperative code

Share this video with your friends

Send Tweet

A tour of simple functions rewritten as composed expressions using Either set to 8 byte music and colorful flying blocks

Nick Ostrovsky
Nick Ostrovsky
~ 8 years ago

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

Alexander Tesfamichael
Alexander Tesfamichael
~ 8 years ago

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.

Brian Lonsdorf
Brian Lonsdorf(instructor)
~ 8 years ago

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

Egghead
Egghead
~ 8 years ago

Hi,

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

Brian Lonsdorf
Brian Lonsdorf(instructor)
~ 8 years ago

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

Egghead
Egghead
~ 8 years ago

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)?

Brian Lonsdorf
Brian Lonsdorf(instructor)
~ 8 years ago

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.

Luis Silva
Luis Silva
~ 8 years ago

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.

Nik
Nik
~ 8 years ago

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.?

Yannick
Yannick
~ 8 years ago

@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.

Noyan
Noyan
~ 7 years ago

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 :)