My apology I didn't reply at the time as I wasn't across the OutMsg pattern and had less experience with the issues you describe. Now I re-read your comment and it makes sense to me.
I attended Elm Europe again this year and saw a couple of presentations where it came up, including an attempt to provide an actor approach to component structure and messages.
My concern with various attempts is when we get scaffolding code doing delegation and tricks that have no meaning otherwise in the application, making it an issue for future users of the code. The Elm language appears to be simply missing some useful structures built-in that would help componentise.
I agree with keeping all messages in one place. I recently did a project where I have them in the same file but broke them up by using a msg wrapper and msg types for each component. This works well for both bug finding and readability.
Thanks for the link to the article. We use some of those same patterns.
Lately, we have started to match both model and msg in our update function. Since messages are top level, you can technically receive a message which is not valid for the current view. This accounts for that case and also nicely unwraps the page-level model and msg all at once.
// F#, using Elmishmatchmodel.Page,msgwith...|CoursePagepageModel,CourseMsgpageMsg->letnPageModel,effects=Course.updatepageMsgpageModel{modelwithPage=CoursePagenPageModel},effects|CoursePagepageModel,badMsg->// log?model,[]
This works with navigation. For example, it is pretty easy to parse the URL /course/abc123 into OpenCoursePage "abc123". We ended up with too many OpenXX messages, so they were organized under a wrapper message tag like OpenPage .... Then a central function is responsible for calling the correct page init.
Since these are recurring patterns, I've tried to parameterize it different ways. But that requires some extra abstraction/scaffolding. And then that abstraction must be learned by other devs (including Future Me when I've been away from the code for 6 months). The team ultimately deemed it not worth it compared to an extra line or 2 of very clear (and copy/paste-able) boilerplate.
We will continue to try different things and refine how we organize our MVU code. But this is where we are for now. We have used it for top-level pages and for 2nd level sub-pages.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Kasey,
My apology I didn't reply at the time as I wasn't across the OutMsg pattern and had less experience with the issues you describe. Now I re-read your comment and it makes sense to me.
I attended Elm Europe again this year and saw a couple of presentations where it came up, including an attempt to provide an actor approach to component structure and messages.
My concern with various attempts is when we get scaffolding code doing delegation and tricks that have no meaning otherwise in the application, making it an issue for future users of the code. The Elm language appears to be simply missing some useful structures built-in that would help componentise.
I agree with keeping all messages in one place. I recently did a project where I have them in the same file but broke them up by using a msg wrapper and msg types for each component. This works well for both bug finding and readability.
You can see my blog post about it here: Keeping it simple beyond a basic Elm app
Thanks for the link to the article. We use some of those same patterns.
Lately, we have started to match both
modelandmsgin our update function. Since messages are top level, you can technically receive a message which is not valid for the current view. This accounts for that case and also nicely unwraps the page-level model and msg all at once.We handle page changes within the same structure.
This works with navigation. For example, it is pretty easy to parse the URL
/course/abc123intoOpenCoursePage "abc123". We ended up with too manyOpenXXmessages, so they were organized under a wrapper message tag likeOpenPage .... Then a central function is responsible for calling the correct page init.Since these are recurring patterns, I've tried to parameterize it different ways. But that requires some extra abstraction/scaffolding. And then that abstraction must be learned by other devs (including Future Me when I've been away from the code for 6 months). The team ultimately deemed it not worth it compared to an extra line or 2 of very clear (and copy/paste-able) boilerplate.
We will continue to try different things and refine how we organize our MVU code. But this is where we are for now. We have used it for top-level pages and for 2nd level sub-pages.