![]() It means that when you generate a new section, we'll create the associated javascript file with all its lifecycle methods and we'll do all the plumbery for you. Regarding the sections and more specifically the javascript events as described here, we also made the integration with Webpack easier. Since the philosophy behind LocomotiveCMS is to remove the painful tasks involved in creating websites, we decided to integrate Webpack inside Wagon so that spinning up a new project takes as little time as possible. This is an incredible tool which, unfortunately, can be a burden to set up correctly. To achieve this, developers came up with tools. However, in top of that, frontend developers must use a tool to compile all the package assets required by their sites. Those Javascript libraries or packages are managed through a central repository (npm) dealing with dependencies and libs versioning. Sites now embed a lot of Javascript code in charge of handling animations and building complex UI components. Things have changed a lot in the Javascript world. HMR can be used in development as a LiveReload replacement. Assets were gzipped without any weird configuration. Nothing to setup, it just works out of the box. One of the nice things about Sprockets is its super easy installation. etc) and Javascript (CoffeeScript, ES6) assets. So as of now, live reload will have to suffice.For a long time, Wagon had been using Sprockets to process and compile CSS (Sass, Less. There is a WIP plugin called “Federated Module Reloading” being worked upon, but it’s still in very early stages. See this and this issue on webpack repos to understand why. The issue is that currently HMR doesn’t work with module federation. This is great, because it saves even more time. The next level of this is Hot Module Replacement, wherein the host app won’t need to be reloaded, and the changes will be applied instantly without page refresh. What we configured was Live Reload, which means that on detecting changes, the host app page will refresh. Whenever you make a change in remote, the host app will reload itself, thus reflecting the changes you did in remote. With these two small changes, live reload will now work in your module federated app. ![]() Modifying host app’s webpack configĪdd the following to your host app’s webpack config, which, in my case, is CRA. ![]() The second point will make sure that the changes that happen are written to disk, and then due to the config in first point, host’s app will pick up those changes and trigger a reload. Configure remote app’s webpack dev middleware to write the bundle files to disk, rather than serving from memory.Configure host app’s webpack dev server to watch for changes in the remote app’s directory.It’s not necessary for the host app to be CRA, it can be anything. Normally, the host app won’t reload since it doesn’t directly know that the remote module has changed. And, when you make changes in the remote module, you want your host app (CRA) to reload so as to reflect those changes. Let’s say the CRA app you are working with depends on a federated remote module. So, I thought of writing this post to provide a quick solution in case someone else faces the same issue. ![]() I faced this issue, and couldn’t easily find good solutions, and had to dive a bit deep into webpack docs. ![]() This is a rather short post describing how to enable hot reload in a module federated CRA. ![]()
0 Comments
Leave a Reply. |