idi527
Has anyone used lazy loading in a phoenix live view project?
I’m currently in a process of optimising the client part of a liveview app and wondered if anyone had tried using lazy loading with liveview.
My current approach is:
- Import heavy dependencies like charting libs with dynamic imports in liveview hooks:
async function createChart(config, el) {
const [am4core, am4charts] = await Promise.all([
import(/* webpackChunkName: "amcharts4-core" */ "@amcharts/amcharts4/core"),
import(/* webpackChunkName: "amcharts4-charts" */ "@amcharts/amcharts4/charts"),
]);
return am4core.createFromConfig(config, el, am4charts.XYChart);
}
const ChartHook = {
config() {
return JSON.parse(this.el.dataset.config);
},
async mounted() {
this.chart = await createChart(this.config(), this.el);
},
beforeDestroy() {
this.chart.dispose();
},
};
export default ChartHook;
-
Add
chunkFilename: "[id].[contenthash].js"option to webpack config to allow for cache busting when the chunks change, note that this doesn’t affect the filenames of the entry points likeapp.jssince the hash there is added bymix phx.digest -
(Optional) Compress
/\.(js|css|svg)$/via webpack using brotli, because why not (and in part thanks to #3840). This would mostly affect the chunks. -
Update
Plug.Staticoptions inendpoint.exto includegzip: true, brotli: true
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 10 of 11 Posts
bglusman
I have no experience/knowledge here but it sounds like a great idea! I wonder if there’s even a chance LiveView would welcome the changes upstream as a PR/if it would be easier to accomplish cleanly within LiveView itself if you fork it? Maybe open an issue on LiveView to see if they have thoughts/are open to it in a PR, or as a hook/config option to make it easier to do within a Phoenix app if it adds some complexity? And I’m curious what you find, it seems like a good idea, but I’ve never tried it in general so not sure how much complexity/what the tradeoffs are…
idi527
I think it’s easy enough to do without any extensions from liveview so I made a small example which roughly follows the steps outlined in OP: https://github.com/syfgkjasdkn/lazy-live-view/commits/master.
sfusato
I’ve recently come across asset_import. You might find it interesting.
How do you handle
.br(brotli) files sincemix phx.digestskips digesting those files? I mean, in the end, you need to have something like:What’s the easiest way for the
brfile generated by Webpack to end up with the same hash as the others?idi527
I use
chunkFilename: "[id].[contenthash].js"in webpack. I don’t think I need the hash to be the same as frommix phx.digestsince I don’t reference these files in phoenix. Webpack does all the lazy loading.Thanks, will check it out. But I think I like the dynamic import approach better.
sfusato
How about your entry file? Or you don’t brotli compress that?
idi527
That’s right, the entry file is only gzipped bymix phx.digest.sfusato
My entry file as well as the app’s css file would benefit from the brotli compression. I ended up writing a mix task that will add the hash to the
.brfiles generated by Webpack.idi527
I’ve just checked and
app.jsandapp.cssget returned as brotli compressed in chrome and firefox with the above setup.sfusato
In prod or in dev? In dev it should work as is, as Phoenix is not referencing them by their hash name. But in prod, Phoenix will switch to the digested file from
cache_manifest.json. In which case, the brotli equivalents will need to have the same filename in order to be used.Also, my app is behind Nginx and you can configure Nginx to brotli compress on the fly or/and use static already compressed files. If you also use Nginx in front of your app, maybe you’re seeing the files compressed on the fly.
idi527
In prod. The file with a hash in its name is compressed. No nginx.
cache_manifest.jsonincludes brotli files. I think it might be thanks to Do not digest Brotli compressed files by jayjun · Pull Request #3840 · phoenixframework/phoenix · GitHub