-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update to ES6 | ES2015 #235
Conversation
... doh
I havn't updated I remember an article about one complaining about the use of Anywho just need guidance on preferred coding style and then I will update the rest. |
@christiantakle see #83 |
@gabrielflorit I'm not sure what it is you want me to see, #83 was mentioned in my other PR and it doesn't seem like there is any conclusion. Nothing is holding us back from turning this branch into an ES6 version of the book. I just wanted to start doing actual work. |
Using Cheers. |
There is a little bit more. Even |
Oh I see @christiantakle - didn't notice you were already aware of #83. |
I think What do you prefer? const fn1;
const fn2;
const fn3;
// vs
const
fn1,
fn2,
fn3; Personally I remove as much syntax as I can so I'm biased. I will just do what the majority like. |
I think it would be nice if the style was consistent with the es6 code in @DrBoolean's Prof. Frisby videos, eg: https://youtu.be/oZ6C9h49bu8?t=10m36s uses
|
@kwijibo excellent proposal. I will follow that style for starters. |
I agree with @kwijibo. It also corresponds to the "JS Standart Style"-initiative. |
Lichtjaeger 👍 I need to think about how I handle extensions of Its a bit problematic in chapter 10 since its shown how After that I will update enviroment for readers to play/test the code. |
show = post => Views.show(post), | ||
create = attrs => Db.create(attrs), | ||
update = post => Db.update(post, attrs), | ||
destroy = post => Db.destroy(post); | ||
|
||
return { | ||
index: index, show: show, create: create, update: update, destroy: destroy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why about using object property shorthand here :) ?
return { index, show, create, update, destroy }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, I will update that
Nice job so far @christiantakle 👍 What about taking advantage of the import/export and destructuring features offered by es6... In a way, that could make the examples more concise and clearer whereas we loose the explicit dependency reference :/ const mediaUrl = _.compose(_.prop('m'), _.prop('media'))
const mediaToImg = _.compose(img, mediaUrl)
const images = _.compose(_.map(mediaToImg), _.prop('items')) We can end up with something like this: import { compose, prop, map } from 'ramda'
const mediaUrl = compose(prop('m'), prop('media'))
const mediaToImg = compose(img, mediaUrl)
const images = compose(map(mediaToImg), prop('items')) Not a huge change but I'd rather like the second form though. |
If using ES2015 syntax then this makes the example clearer IMO. 👍 |
I'm thinking of going this way as you can see here: https://github.com/MostlyAdequate/mostly-adequate-guide/pull/235/files#diff-eca58e722edd3254515254f62175aac0R130 Consistency is my most important goal, so most changes are currently partial/rough. I will iterate over everything again to polish rough edges. I'm writing Haskell at my everyday work and in bigger examples its actually nice to important functions qualified since many of them have the same name. Its different in Javascript though. |
Short update, sorry for being busy. I will start working on this PR again. Cheers |
If I follow you correctly: I think it makes sense to just create a separate class for each |
@thurt Thanks for the input that makes a lot of sense. We can take inspiration from the Purescript refinements of the Haskell type classes. http://blog.functorial.com/posts/2015-12-06-Counterexamples.html, see The Monad Hierarchy |
@christiantakle I just finished the book yesterday and haven't programmed in FP style before. So I am having trouble understanding some of the type signatures and logic in the link you provide--I may not be much help beyond this. My main impression from the contents of the book:
|
@thurt Its very insightful input I've been doing it for a while so I can accidentally make things harder than its need to be. Your basic intuition is correct, however its important that the implementation follow some laws e.g. Functor lawsmap id = id
map (f . g) = (map f) . (map g) AsideThe hierarchy is: Which is the reason you can derive them from each other e.g. chain = (m,f) => join( map(f,m) )
map = (f,x) => chain(x,(compose(of, f))) Taken from https://en.wikibooks.org/wiki/Haskell/Understanding_monads#Monadic_composition |
#273 revives this PR |
I think we should update the text and provide a better OOP example. The code is still very verbose. We could also keep the current mutating code and just call it imperative instead of OOP.
Based on: https://gist.github.com/eshacker/be153d852b9b995f42dd