At NoRedInk, we use a single elm code base with multiple entry points for each different page with a unique elm app. This is ideal in terms of build time and reliabitly, as everything can be built and once and share a single lot of packages.
We also use the webpack loader for this style of app (though to be fair, we made it). On Thu, Nov 24, 2016 at 3:07 AM, Robin Heggelund Hansen <[email protected]> wrote: > I would just keep everything in one Elm app, then use a router to display > the correct page. > > When it comes to google closure, Elm only works with SimpleOptimizations. > There are two-three lines in the runtime which causes problems with > AdvancedOptimizations. > In any case, the difference between Google Closure and Uglify is very small > when it comes to Elm. In my app, Uglify brings size down to ~80Kb, while > Closure with AdvancedOpts brings it down to ~74Kb. When gzipped, the > differences are barely noticeable. > > > onsdag 23. november 2016 19.49.19 UTC+1 skrev Rafał Cieślak følgende: >> >> For the posterity, I implemented said "architecture" in one of my side >> projects. https://github.com/ravicious/rails-elm-forms/commit/b5ac6964f >> >> The only difference from what I said above is that the Elm apps don't have >> their own entry points in the webpack config. Instead, the entry points are >> the JS file which require the Elm file and then embed the app. >> >> I wish I could use Closure Compiler, but I couldn't get the trio (Closure >> Compiler + webpack + Elm) to work together, for some reason the two webpack >> Closure Compiler plugins I tried to use mess up the Elm code. >> >> On Saturday, November 19, 2016 at 9:58:27 PM UTC+1, Rafał Cieślak wrote: >>> >>> The project I'm working on is not a SPA, it's a rather big Rails app that >>> sometimes needs JS to make some part of the page dynamic – usually it's >>> about dynamic forms. >>> >>> When I was thinking about ways in which I can integrate Elm into the >>> project, I thought about having a separate Elm project for each feature: so >>> there would be an order_form folder with its own elm-package.json, its own >>> versions of dependencies and Elm. Beside it there would be another folder, >>> let's say product_form, also with its own elm-package.json and so on. >>> >>> I quickly realized it could be a nightmare from the maintainability point >>> of view, since each folder would require its own version of Elm, thus each >>> folder would need to have a separate package.json which would install Elm >>> from npm. >>> >>> I looked at elm-webpack-loader and found out that it requires me to have >>> a single elm-package.json for the whole project. Separate forms would have >>> an access to the same dependencies and the same version of Elm. At first I >>> was put off by this solution, as it was completely the opposite of what I >>> had in mind (separate elm-package.json for each form). Finally, I had a >>> sudden moment of clarity and I realized that what elm-webpack-loader does is >>> exactly what we already do with our smaller React apps: each lives in its >>> own directory, each has a separate entry point in webpack config, but all >>> share the same package.json and all have access to the same deps. >>> >>> Do I get it right? If so, how should I structure the apps on the Elm >>> side? >>> >>> I was thinking about creating a directory app/assets/javascripts/elm. >>> Each Elm "app" would have its main module under >>> app/assets/javascripts/elm/src. Each Elm "app" would also have its own entry >>> point in webpack. app/assets/javascripts/elm/src would be added as a source >>> directory in source-directories in elm-package.json. Then I could >>> "namespace" each "app", so that there's OrderForm (the main module) and >>> everything that is specific to it is nested under OrderForm (OrderForm.Foo, >>> OrderForm.Bar). >>> >>> This way webpack could easily handle building all the Elm apps along with >>> React apps. >>> >>> Are there any pitfalls in my thinking? Do you see ways in which this >>> approach could fail? If you use elm-webpack-loader and had a similar >>> problem, I'd love to hear how you handled it! > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
