I mean: save state to IDB on every mutation; onLoad just read from IDB and pick up where we left off. No need to partially patch an app
So if an application is always the function of state; would a viable HMR technique be to persist state to IDB and load state on restart?
-
-
-
Obviously that wouldn't work with widgets that have self-contained state, but does that really matter? I don't think so ... f5-f5-f5-f5-f5
End of conversation
New conversation -
-
-
even further, as far as most of your state exposed via URL, you don't need to store this somewhere else at all
-
not _quite_ true; half-filled in forms for example aren't reflected in a url; url's have hard length limits too
- 1 more reply
New conversation -
-
-
+1 confirmation point that it's a good idea then :D
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
oooohhhhh - do you have a code example for this? Having this for choo would be
!Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
radddddd! :D
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
ooooh, yesssssss! Thanks hey :D
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Your approach reminds me this : https://github.com/reactjs/redux/pull/1455/files#diff-3528551360d976100bc41367b5b62412 …
-
except that in your case, the redux store would be replaced by IDB
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.