Yeah. I'd tried other bootstraps before that one came along, and while some of them are a little better at live hot-swapping (as opposed to just sending a signal to totally restart your app from the beginning) the nature of Alt stores and actions is such that in-place hotswapping rarely works, so there's little to gain from it.
So I also today recommend create-react-app and then npm install --save to get alt and your UI component libraries.
Warning: setState(...): Can only update a mounted or mounting component. This usually means you called setState() on an unmounted component. This is a no-op. Please check the code for the AltContainer component.
We can go a long time without hitting this, but once we do, and we've no idea what the trigger is, it repeats (ad naseum) forever until the app is reloaded. Anybody have any idea what we might be doing wrong that is causing it to trigger? None of the functionality seems broken, we see no visible 'bugs' in our stores or data on screen.
actually what you were doing is right. the altContainer intentionally fires a redraw on its children when any change happens. that's its job.
so you need to use shouldComponentUpdate in your components to keep them from changing if the state changes for reasons it doesn't care about.
optimizing that can happen in 2 ways. 1) use multiple stores and multiple alt containers around different parts of your app, or 2) have a controller component that divides up the properties of the store into separate items that the real components need to know, so they don't necessarily rerender because their own properties might not be changed.
#!/home => home.js
myStore.fetchRabbits. Sometimes, this results in an error that is "expected" (for example the user's access token has expired). These errors get handled fine by the error action I specified when I set up the async source. However, AltJS then rethrows the exception and my console.log fills up with unhandled exceptions.