Fork me on GitHub
#re-frame
<
2019-09-12
>
simonkatz13:09:23

I’m trying the simple example app at https://github.com/Day8/re-frame/tree/master/examples/simple Hot-reloading isn’t working for me. When I make a change, I get “compiling” and “build completed” messages, and a pop-up spinner thing in the browser, but I don’t see the changes. If I refresh the browser, I do see the changes. Any thoughts on why this might be or how to investigate?

malch13:09:20

@nomiskatz Looks like you need to add :after-load (https://shadow-cljs.github.io/docs/UsersGuide.html#_config) to you shadow-cljs config

simonkatz14:09:36

@malch Thanks for the suggestion. I added :after-load simple.core/run, and now I do see the update, but I lose the state of the UI — in that example app, if I’ve entered a new value in the color field of the UI, that gets replaced with the initial value.

p-himik14:09:00

@nomiskatz The issue is that the run function also resets db by dispatching [:initialize]. Try to refactor the rendering code and call just that in :after-load.

simonkatz14:09:43

@p-himik Thanks! So things are working as I expect now.

simonkatz14:09:30

And, just to check — is this how things are supposed to work? There’s not some other deeper problem that I’ve worked around?

p-himik14:09:22

I think that's just that, yeah.

p-himik14:09:50

You also probably need to know about defonce in this context.

simonkatz14:09:18

OK, yes. Cool; thanks again.

rgm14:09:17

I sometimes run into this depending on how high up the view hierarchy the component is. At the very top, yes... only a refresh will work. There’s probably something clever to be done with after-load but I don’t yet understand the hot reload well enough.

superstructor14:09:46

Hey @nomiskatz 👋 Sorry about that issue and thanks to all who helped. A PR with the above changes would be welcome.

simonkatz14:09:16

@superstructor No worries. I’ll create a PR when I get a moment, but I’ll take a look at the other example app first.

superstructor14:09:59

Other example probably has the same issue.

simonkatz17:09:48

@superstructor I looked into fixing hot reloading for the todomvc example, and that was a little trickier. I had to change the definition of todomvc.core/history to use defonce — with a def the reloading caused things to break (the “app” element could not be found in the DOM; not sure what the root problem is there). I also removed what I think was an unnecesary use of window.onload in the HTML. My changes are at https://github.com/simon-katz/re-frame/commits/hot-reloading-in-example-apps. Happy to create a PR (and will do a bit later), but if you want to have a look at what I have done first you’re welcome to.

simonkatz17:09:13

Ah, you are probably asleep. I’ll create the PR.

simonkatz14:09:32

Yes, I had a quick look. It looks the same as the “simple” example.

eskemojoe00720:09:35

Quick security question with re-frame. Is it possible to modify the re-frame db maliciously. I'm trying to restrict access to content based on authentication. I see a lot of people use :authenticated true in their app-db or reagent atom. Could that get set to true without actually talking to the server maliciously?

eskemojoe00720:09:52

Or for high security pages, is it normal to push the hiccup or page from the server to make sure it's not inspectable from the source code even if they aren't authenticated if it all lives on the front end?

eskemojoe00720:09:17

I guess that second question is dumb. You just leave the frontend info pretty blank, then use the API to fill it out. Front end would just have structure which isn't a security concern.

lilactown20:09:13

you should always do authentication / authorization server-side

lilactown20:09:25

you can never depend on the front-end to be truthful

✔️ 8
lilactown20:09:29

e.g. sensitive data should be behind an API that uses an authorization mechanism to determine if the user can see it