-
-
Notifications
You must be signed in to change notification settings - Fork 181
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
React native hot reloading limitation #544
Comments
Technically the issue is in reagent/react. The code is reloaded normally, then the In figwheel a full One simple fix for this is to force reagent to re-render by adding an additional prop. (defn start
{:dev/after-load true}
[]
(expo/render-root (r/as-element [root {:x (js/Date.now)}]))) |
Hi @thheller and thanks for all this valuable informations ! Thx to you to pointing me in the right direction to find the figwheel doc :
Perfect, the trick to adding the variable prop does the job. |
|
If the answer is more complex than that, I will open an new issue but I pose my last question here (for today ;)). Why when reloading app (hard reloading), we loosing the repl connection (and/or websocket) ? With figwheel, if I hard reload the app, the app state is loosing but the repl connection is restored and I can continue to working. |
After "hard" reloading the app, the connection expo message is displaying well:
But if I launch something from CLJS repl, timeout error occurs:
|
Hmm it appears that the websocket is not disconnected when doing a hard reload. It just kinda stops replying I guess. Not sure why that is. Will look into that. |
Thx very much ! N.B. It's seems that is the same issue mentioned to the third point by @Wiltzu: #214 (comment)
|
If it works find in iOS I'm gonna say its a bug in react-native. A quick google shows many other websocket closing relating issues, eg. facebook/react-native#18775 I'm not sure there is much I can do on my side. Since the code of the original app stops running I can't do anything there. I also don't want to forcefully kill other runtimes if a new one connects since that would prevent you from connected with 2 devices at the same time. I would expect the react-native runtime to close all open websockets when the app is unloaded. Maybe there is an event I'm supposed to listen for but I couldn't find it. |
I don't tried on IOS but for me, it works well for the same project with Figwheel...as I say before, I can reload without loosing the REPL connection so I don't think, it's a bug in react-native. Best regards, |
It is definitely a bug in react-native. The websocket remains open. That I confirmed. Figwheel might be using a different logic for runtime selection. In shadow-cljs the first JS runtime that connects is picked and used for eval's. You can pick a specific runtime but that API isn't exposed since no tool currently supports it properly. Since that first JS runtime (ie. websocket) never disappears it never picks a new runtime. Figwheel just might pick the latest? Or just send to everything? I don't know. I could work around react-native not disconnecting but I kinda don't like that since the websocket should just be closing. Dunno, too tired to look into it now. |
OK thank you to help me had a better understanding of all of that ! |
I try to figure out how to handle correctly (like Figwheel does) the hot reloading with Shadow-cljs for React native projects.
If I'm correct, this method handle the reloading :
shadow-cljs/src/main/shadow/expo.cljs
Line 9 in 0e28c61
That works great until the modified file is not the root app.cljs (for eg.) or some another files directly required by this app.cljs.
For better understanding, you can check and test with here prestancedesign/reagent-expo@da58d8f.
@Wiltzu has mentionned this behaviour on this issue #214 :
For the moment, the only solution we had to avoid this behaviour is to use
(ns ^:dev/always app.core)
to force app.cljs to always be recompiled/reloaded.Any ideas how Figwheel handle this and how can implemented this for Shadow-cljs ?
Best regards.
Thx.
The text was updated successfully, but these errors were encountered: