I recently read a lot articles and blog posts about the whole flux stuff and I came across redux. I watched the talk which Dan Abramov gave at react-europe conference (if you haven’t seen it yet: Dan Abramov - Live React: Hot Reloading with Time Travel at react-europe 2015 - YouTube). I really liked the approach of hot reloading and it would be very useful in my daily workflow.
I have an app which needs a lot of time to bootstrap and get to the state back again in which it was. The idea of hot reloading would save me a lot of time since I don’t need to wait for the whole app to bootstrap again and setup the whole UI state.
Basically my question is, if this functionality is available in Ember?
Ember-CLI has had live reloading since the beginning. If you’ve written your app well “the Ember way” so that the url persists your current UI state, you already have it.
That said, Ember doesn’t persist all of your JavaScript state for you.
@Gaurav0 Thank you for your reply. I use Ember-CLI and I love the live reloading feature. But as you said it does not persist all JavaScript state. The live reload is just a page refresh. There are two things which are not perfectly manageable with coupling the state to the URL.
So assume I have a very complex UI and I have many different state possibilities. Now I don’t want to create a URL for every toggled/non-toggled element. Furthermore in our app we use a WebGL feature which needs 20 seconds to boot, render and be ready for user input. If I do a full page refresh via live reloading, I always have to wait 20 seconds which is a real pain in development.
Yes live reloading is nice but in my point of view hot reloading is the next step forward.
I would be surprised if live reloading of javascript becomes a thing in ember, it’s quite a complex problem because of the large amount of state that sticks around in javascript in various places. It’d be nice and especially for use cases like yours but I suspect it won’t be coming soon in any major capacity to ember-cli
You are correct in your assumption about state being the problem.
Dan Abramov built Redux and is using that in order to enable the hot reloading feature.
Redux requires that all state is centralized and reducers are used in order to extract the specific state for each component. Without that mindset / approach, a similar hot reloading is impossible.
@andreisebastianc yes that’s completely true. Hot reloading only works if something similar to Redux is used. I was always concerned about where to store state and I never found a good solution. This is the reason why I came across flux and redux. I really like their approaches. But they seem to be closely related to React. And I wondered if there are similar approaches in Ember. I didn’t found something. Or did I just miss some project or blogpost?
In general non-url state in ember is stored in services. And in fact it wouldn’t be that hard to get to an 80% solution in ember. The problem is that there are loads of other places that state is stored. Closures, global variables, the dom, javascript apis etc.
You mentioned all the toggled / non-toggled element stuff and your webgl feature - but actually not resetting those would be an incorrect solution - they should be reset when hotloading the code as otherwise it’s easy to be in a state that it would be impossible to get to if you had started from a fresh runtime. I have no idea how redux handles these issues but I assume the answer is “OK enough to not be a PITA”.
So i have been writing emberjs apps for almost a year now and at the same time have been writing reactjs, isomorphic apps based on flux then I moved to redux. Hopefully I can help with this discussion.
Bringing it to ember world, hot reloading is possible and much more near than we think. The challenge is on compile time, using babel to find components, wrap them in a proxy that passes all attrs down to the component and saves those attrs internally. Then on file change, it would swap the new component with the old. Then the attrs would be applied downstream as they were before and we are in a good place. I don’t know how it will work with routes but controllers are similar to components I’d assume.
That’s why you see in the video, Redux is not maintaining state on hot reloading because Redux never gets touched at all. And if you were to change any redux related code (reducers or middleware) it’d prompt you to a page reload in the console.
@mmahalwy: thank you for the detailed explanation. So I mixed up some things with hot reloading and redux. Nevertheless I like the idea of redux. I think the issue where and how to store UI state is discussed more depth in the react community than in the Ember community. I like the data-down actions up approach of Ember but I think it does not go far enough. Sometimes it can be confusing where to store the UI state. Should I store it in component X. Or in the “parent” component of component X. Or in the controller? Or the route? Or in a service?
Of course there are suggestions how and where to store UI state but I think it is not always easy to find the right abstraction. I think something like redux could help tremendously to simplify this issues.
Let me know if there are projects going on about the UI-state topic in the Ember community maybe I could contribute a little bit
@krautman I’ve started an addon to bring first class redux to ember and even wrote about how learning redux improved my understanding of “data down actions up” in ember.
The api is stable but 2 parts are missing today that you should be aware of (to help you better understand the tradeoffs)
out of the box we don’t “sync” the router state with the the central store in redux. This may not harm the “hot reloading” story but time travel debugging is a little wonky w/out support for router transitions at the moment.
if you have a heavily relational data structure/ or use the hasMany/belongsTo attrs inside ember-data you will find this library lacking because it’s not that feature rich today.
That said, it does offer full redux/immutability and (early stages) time travel if you are interested. It’s also something that we could technically play with to see how “hot reloading” would work with ember-cli at some point because the state is truly stored in a single place (redux) so you could reload a handful of components and they would all reflect the correct state (so long as you use redux to store anything changed in the UI).
If you want to play with it (and time travel), install the redux chrome dev tools extension and pull down this ember-cli project
You should probably first give yourself an overview of Cerebral, which is like redux, and strictly enforces the data down, actions up paradigm: http://www.cerebraljs.com/
Cerebral includes it’s own debugger that is the bees knees for tracking and managing state while debugging, the full evolution of what Dan introduced in the talk at the beginning of this thread: New Cerebral Debugger PREVIEW - YouTube
Working on getting a deployed version of bfitch’s TodoMVC example so that ya’ll can easily get a feel for the awesomeness… but for now:
git clone https://github.com/bfitch/ember-cerebral-todomvc.git
cd ember-cerebral-todomvc; npm i; bower i; ember server;
Hey @toranb would you have any personal advice/opinions on using ember-cerebral or ember-redux for a new ember app? Have you tried using the redux dev tools extension with ember-redux? At a basic level, cerebral offers the cerebral debugger, so I was going to go with that, but I haven’t tried using the redux devtools extension with ember-redux.
@DevinRhode2 I’ve got a screencast I just recorded that shows this in action w/ ember-redux (hot reloading/ time travel and “the future” as I see it). But because it’s a pending talk for So Ember I can’t release it publicly (the title would give it away for the organizers). If you want an early preview just let me know toranb at gmail
@DevinRhode2 turns out I didn’t make the cut for SoEmber this year … but the good news is that I can share my talk on ember/redux/hot reloading/time travel early
maybe I could contribute a little bit
there are commits during the last 3 days. So I seems to be still maintained 