pfun

pfun OP

I did manage to confirm that you are correct – reloading the page does cause the new logger (or whatever changes) to be reflected. If you edit something in _web it triggers live reload, but also just refreshing the page (which as you mentioned would spawn a new liveview process for the page) also works.

Is this really the intended behaviour? I swear this has never been an issue before in other liveview apps. Maybe I’m mistaken.

So for the sake of my experiments I’m just heavy-handed adding:

~r"lib/<appname>/.*?/.*"

to my live_reload config, kinda like @kokolegorille suggested originally. I hope this isn’t really the intended way to solve this situation though :expressionless:

0
Post #11
beepbeepbopbop

beepbeepbopbop

Is this really the intended behaviour?

Well, I would imagine so. Reloading the browser simply works since it’s going through the set of plugs that handle this problem. However, I would imagine that the alternative of having your LV processes run the code reloader per message is probably worse. It would be possible to add a Plug like setup to your LV, but the overhead would be far from ideal. I personally don’t really deal with this problem specifically since I write the core code, have tests that run against that and then wire it up with LV.

Using recompile in an iex shell does give you more control when to recompile, but I can imagine that runs against the dev userflow for some people.

1
Post #12
pfun

pfun OP

I guess I’m expecting a code change to nuke and restart any liveview processes that have outdated code. I’ll have a look and experiment with older liveview apps and see what happens there, but yea my dev workflow is definitely a “poke at it in the browser while making changes across the entire codebase”, usually. It’s just hobby stuff.

0
Post #13
beepbeepbopbop

beepbeepbopbop

I guess I’m expecting a code change to nuke and restart any liveview processes that have outdated code

I suspect that you might have had a more aggressive configuration for LiveReloader in this instance. LiveReloader would have picked up your core changes and propagated them to cause the “nuke” on your LV process. LV definitely does take it to the next level, but it also adds a new set of problems to be solved.

0
Post #14
Rugged

Rugged

I confirm this behavior, I am very new at phoenix and would likely report the flaw poorly as I do not know elixir specific terminology. If/when you make the github issue, please link it so that we can follow.

Thank you in advance.

0
Post #15
zolrath

zolrath

Just for good measure, I can confirm this as well!

Was surprised to not see behavior changes when editing a function in the <appname> portion of my project and remembered seeing this post!

0
Post #16
pfun

pfun OP

Alright so as @beepbeepbopbop was suggesting, this is apparently just normal behaviour. I used Phoenix 1.6.15 to make a new app and did:

mix phx.gen.live Things Thing things title:string count:integer

Added routes as instructions say, started server, made a ‘Thing’. Then I added a validation in thing.ex, e.g. add:

    |> validate_number(:count, less_than: 10)

Made a new Thing, and it let me make it with count: 500. Refresh the page and now the validation applies. Same with adding loggers. Nothing happens until you refresh the page (or recompile() when using iex). I definitely just want this to happen automatically, so I suppose I have to do the live_reload config ugliness I mentioned earlier.

I worked on an app early on with liveview (that unfortunately I can’t get to work at all anymore) and I really find it hard to believe I never noticed or encountered this. I did not make any changes to the live_reload config in that other app, totally vanilla as far as that’s concerned…

But, anyway, seems clear this is just expected and not a bug at all, folks. Thanks for all your input!

2
Post #17
— All posts loaded —