Re: [elm-discuss] Structuring a simple App
That is precisely how some of it is done (written more recently), the part I showed above was one of the first bits written back when everyone was saying "make model and msg flat!", I do not do that anymore and do need to refactor, but it does bug me how people keep saying to make everything flat instead of separate by logical concerns in the first place... On Thursday, September 22, 2016 at 11:52:59 PM UTC-6, Joaquín Oltra wrote: > > OvermindDL1 why not refactor out that part of update as another function? > With 24 and 8 actions per logical system it definitely seems like a > separate update (& maybe model) would benefit the maintainability. > > Also why not keep the action constructors separate? (Room Joined) You can > case on them easily and to create then when emitting them you can compose > them as functions or use Html.App.Map. What's the benefit of namespacing > them with underscores? > -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Structuring a simple App
OvermindDL why not refactor out that part of update as another function? With 24 and 8 actions per logical system it definitely seems like a separate update (& maybe model) would benefit the maintainability. Also why not keep the action constructors separate? (Room Joined) You can case on them easily and to create then when emitting them you can compose them as functions or use Html.App.Map. What's the benefit of namespacing them with underscores? -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Structuring a simple App
Hold on folks. All of this is motivated by wanting to be able to change a text box for a slider, yes? You want an interface, not a component. The Msg type should include a SetSpeed Float tag. The view should have the input send this Msg. The view can also expect to use the current speed in constructing the UI, either as the text box value or the slider position. Also, it's not the end of the world if you have to change update. Elm makes refactoring very low-risk! -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Structuring a simple App
I would still like to find a good way to structure messages. I'm up to 146 in the base Msg type, and it is not flat, by counting it seems that I have 6 message types that just hold another message type for something further down, which average in size from 2 for 1 of them, 4 for 3 of them, 8 for 1, and 21 for another (and that 21 is growing as well). I kind of namespace the message type by following a naming convention of `_`, like this set at the top for example: ``` | RoomList_Init Int (List RoomDef) | RoomList_Joined Int (List RoomDef) | RoomList_Parted Int (List RoomDef) | RoomList_Notif Int (List MsgObj) ``` It works, but does not feel right, like I feel the whole Room handling stuff should be delegated out too, but that just ends up going further out of 'flat' messages that everyone keeps saying to do here, but I really feel like that is the wrong way and about to swap all this to a tree of messages as the couple that are like that work really well... >.> On Thursday, September 22, 2016 at 3:17:23 PM UTC-6, Charlie Koster wrote: > > As far as Msgs go, why not just flatten it since it's, as you say, a > simple app? > > type Msg > = NoOp > | Component1Msg > | Component2Msg > > We decided to go down that route on our project and we currently have 10 > Msgs, and it will likely grow to be a few dozen. Unless there's a really > good reason to refactor it, we'll keep growing that flattened list. > > In regard to the rest of the app architecture and organization, we're > experimenting with that as well and we think we have a good implementation > going. I'm actually planning on publishing the decisions we made with our > app as well as our repository with its git history so people can look at > the history of how our app came to be. > > Unfortunately, we're still 6-8 weeks away from getting it to a > publish-able state so sorry that it's not much help right now. > -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Structuring a simple App
As far as Msgs go, why not just flatten it since it's, as you say, a simple app? type Msg = NoOp | Component1Msg | Component2Msg We decided to go down that route on our project and we currently have 10 Msgs, and it will likely grow to be a few dozen. Unless there's a really good reason to refactor it, we'll keep growing that flattened list. In regard to the rest of the app architecture and organization, we're experimenting with that as well and we think we have a good implementation going. I'm actually planning on publishing the decisions we made with our app as well as our repository with its git history so people can look at the history of how our app came to be. Unfortunately, we're still 6-8 weeks away from getting it to a publish-able state so sorry that it's not much help right now. -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Structuring a simple App
Perhaps the idiomatic way is just forwarding, as in this from https://medium.com/@_rchaves_/structured-todomvc-example-with-elm-a68d87cd38da#.prhqa9c5n type Msg = NoOp | MsgForComponent1 Component1.Msg | MsgForComponent2 Component2.Msg -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
