finally, a slide deck that uses `history.replaceState` instead of `history.pushState`. no more having to hit "back" 90 times to exit the deck. how the latter ever became a pattern is beyond me. [EDIT] it probably became a pattern because of browsers that didnt implement the history API, so all hashchange events were pushed onto the history stack.
My rule is pushState() makes sense in apps when changing views , say from a "List of X" to the "Edit X" view. The back button should then take me back to a "List of X".
In this case it doesn't make sense as you remain in the "slide" view the entire time.
To be honest, using replaceState for this doesn't seem to make sense to me. A user would probably want to go backward and forward through this using browser history navigation (for instance using the navigation buttons on their mouse). If you're launching a link from a page you expected to come back to, surely opening the link in a new tab would be the way to accomplish this?
personally, i've always used arrow keys, swipes, pgup/pgdn to nav between slides. i want a single-action "exit slide deck to previous page", and the browser's back is the logical place for that to be, imho.
I think the lines between a single page app and full page reloads needs to be blurred. Most people won't know the difference and the back button needs to behave consistently.
For that reason, I think that pushState here would make more sense. The state of the page does, after all, change.
Bravo for promoting functional programming and showing how it can be done in JavaScript. One issue concerns me, though: using strings to reference attributes. This makes static checking tools much less useful and can lead to difficult to find errors due to refactoring and typos.
Bravo for promoting functional programming and showing how it can be done in JavaScript. One issue concerns me, though: using strings to reference attributes. This makes static checking tools much less useful and can lead to difficult to find errors due to refactoring and typos.
Promoting FP using SQL as an example for encoding business logic doesn't look to me like a nice example...
For those you want to learn the functional programming I'd suggest to immedeately commence looking at Ocaml/Haskell instead to see the real big picture. Because it's of course adorable that you can write map and compose in JS (it's 2014, it can do it everywhere), but FP = many more serious things.
Edx has a course in functional programming using Haskell. I haven't taken it yet but I'm going over Christmas.
personally, i've always used arrow keys, swipes, pgup/pgdn to nav between slides. i want a single-action "exit slide deck to previous page", and the browser's back is the logical place for that to be, imho.
I think the lines between a single page app and full page reloads needs to be blurred. Most people won't know the difference and the back button needs to behave consistently. For that reason, I think that pushState here would make more sense. The state of the page does, after all, change.
it's not a mental "context switch", though. i think the way android has the back button implemented is very sensible.
finally, a slide deck that uses `history.replaceState` instead of `history.pushState`. no more having to hit "back" 90 times to exit the deck. how the latter ever became a pattern is beyond me. [EDIT] it probably became a pattern because of browsers that didnt implement the history API, so all hashchange events were pushed onto the history stack.
You could always do it right with `location.replace`, but that was never as common as it should have been.
In my experience, FP in javascript leads to easy to read, stylish code that runs far slower than more traditional code. I have benchmarked the array builtins, underscore, lodash, and fastJS vs a simple set of nested loops and the for loops blow everything away. I love FP, I've been doing my side projects in Haskell for the last few months and love it. But when my Node server responds noticeably slower because I'm consuming a database query with functional patterns instead of loops, I use the loops. I still use FP where I believe it fits and provides benefits, but I'm not married to it when using JS. The point is, is I keep seeing people pushing FP in JS really hard and no one every says, "Warning, you are sacrificing performance". The performance hits don't matter much of the time, but sometimes it does and everyone pushing FP seems to push it like if you're not using FP in JS you're bad and you should feel bad and that's just not true.