Elm 檔案結構 簡易架構觀念

• https://guide.elm-lang.org/webapps/modules.html

• https://guide.elm-lang.org/webapps/structure.html

I tend to use it for import Html exposing (..) but not on anything else. For everything else, I recommend using the standard import and maybe using as if you have a particularly long module name!

I encourage you to push your limit on number of lines! See how far you can go. Try using comment headers, try making helper functions, but keep it all in one file. Having this experience yourself is extremely valuable!

Some folks see The Elm Architecture and have the intuition to divide their code into separate modules for Model, Update, and View. Do not do this!

If you build each module around a type, you rarely run into these kinds of questions. You have a Page.Home module that contains your Model, update, and view. You write helper functions. You add a Post type eventually. You add an estimatedReadTime function. Maybe someday there are a bunch of helpers about that Post type, and maybe it is worth splitting into its own module. With this convention, you end up spending a lot less time considering and reconsidering module boundaries. I find that the code also comes out much clearer.

Thinking in terms of components encourages you to create modules based on the visual design of your application. “There is a sidebar, so I need a Sidebar module.” It would be way easier to just make a viewSidebar function and pass it whatever arguments it needs. It probably does not even have any state. Maybe one or two fields? Just put it in the Model you already have. If it really is worth splitting out into its own module, you will know because you will have a custom type with a bunch of relevant helper functions!

Point is, writing a viewSidebar function does not mean you need to create a corresponding update and Model to go with it. Resist this instinct. Just write the helper functions you need.