Strange elixir behaviour

[AZholtkevych]

https://dockyard.slack.com/archives/C02E1GA5THB/p1702234776493379

I discovered a strange elixir quirk when I renamed live_view_native_swift_ui to live_view_native_swiftui 2:02 Compilation was failing within live_view_native because LiveViewNative.SwiftUI was uncompiled. It seems changing that app name changed the compilation order of the dependencies. Because live_view_native and live_view_native_swiftui don't depend on one another there is no way to inform the compiler that one must be compiled before the other. The way we'd typically do that is to set live_view_native_swiftui to be a dependency of live_view_native so it will compile live_view_native_swiftui first and LiveViewNative.SwiftUI would be available at the compile-time for live_view_native. But we cannot do that because the live_view_native library really shouldn't be away of clients. 2:02 this block of code: https://github.com/liveview-native/live_view_native/blob/main/lib/live_view_native/platforms.ex#L6-L17 platforms.ex @env_platforms :live_view_native |> Application.compile_env(:plugins, []) |> Enum.flat_map(fn plugin_mod -> apply(plugin_mod, :platforms, []) end) |> Enum.concat(@default_platforms) |> Enum.uniq() Show more https://github.com/[liveview-native/live_view_native](https://github.com/liveview-native/live_view_native)|liveview-native/live_view_nativeliveview-native/live_view_native | Added by GitHub 2:04 in LVN its doing a compile-time collection of all plugins. I assume this was decided for performance reasons so the plugins don't need to be re-discovered constantly at runtime. However, because of the compilation order change due to the name change this was failing because live_view_native_swiftui was now compiling after live_view_native. I suspect it worked with the previous name due to simple luck of however Elixir decides compilation order of dependencies that are not bound to one another (edited) 2:04 The simple fix for now is to move that into run-time and cache the result in ets 2:05 however we'll probably need to re-think this long-term. I hope that a bunch of the code can be refactored out as we get Phoenix and LiveView upstream to work with formats and such. We should be able to simplify the lib quite a bit at that point 2:06 and the plugin system could also benefit from this 2:06 thanks to @Paulo Valente for the pairing to figure this out today 2:07 exactly how Elixir is determining order and if that is a bug is unknown, kind of strange the compilation order would change like that due to a removal of a single character 2:07 the alphabetic sort order doesn't change, so order must be determined in some other fashion

bcardarella 2:23 PM I'm working on a patch that will store and fetch from an ets cache so we don't incur the runtime overhead

bcardarella 5:01 PM @Carson Katri I tried using http://localhost:4000/thermostat as the url for connecting to a LV app and the client appears to be just trying http://localhost:4000/ and not including the path... I'll dig through the swift code but are paths being stripped out?

bcardarella 5:10 PM I suspect the issue is in LiveViewHost.swift

bcardarella 5:29 PM ah nevermind, looks like I can do .localhost(path: "thermostat") that's cool but think the full string host + path should also work

bcardarella 11:03 PM is live reload broken still?

[bcardarella]

This isn't valid, the list of slack conversation is related to two separate issues.

[AZholtkevych]

My fault, @bcardarella . Issue is #1187 . Thanks a lot