Thank you Joaquín, I finally found a solution by doing something similar to 
what you did with the update function returning another element. The main 
difference is that I want to being able to send command from the child 
command and add other commands from the parent on certain events. I'm doing 
so by using *Cmd.batch*.

I was stuck exactly because of the attempt to create multiple modules where 
they are not really reusable nor logically separated. So, I agree, the most 
elegant solution, is to NOT split modules, and keep things togheter.
I'm about to try to introduce elm at work and I struggling to understand 
the bounduaries of elegant code, code that works, modularity vs single 
module, reusable functions etc. This is for me the most difficult part so 
far. Everything else, given I'm used to a dynamic language like elixir (and 
before php), feels really good, even compared to awesome workspaces like 
react+redux.

Thanks again for your great answer, despite the poor information I gave, I 
didn't want to clutter the post with 200 lines of code :) 


Il giorno domenica 18 settembre 2016 01:28:55 UTC+2, Joaquín Oltra ha 
scritto:
>
> Without seeing the full code it is hard to give better advice. Here's an 
> example:
>
> An isolated SearchForm TEA: 
> https://github.com/joakin/gimme-gif/blob/1e5e347f2118e3ea5d05f37d6a71764b6c85e7e7/src/Components/SearchForm.elm#L22-L33
> See the highlighted lines for the returned component event instead of an 
> elm Cmd. Previously I've had that update function return a 3 tuple with 
> commands if needed: update : Msg -> Model -> (Model, Cmd Msg, Maybe Event) 
> which seems like what you need. The order doesn't matter, do it as you 
> please.
>
> See the SearchForm wired up in the main App.elm: 
> https://github.com/joakin/gimme-gif/blob/1e5e347f2118e3ea5d05f37d6a71764b6c85e7e7/src/Components/App.elm#L43-L53
> That's where the parent TEA component deals with the form event, and acts 
> on it by triggering a Cmd, etc.
>
> As mentioned elsewhere, making full TEA (init,update,view,subscriptions) 
> reusable components in elm can be painful to wire up, so I would suggest 
> not doing so unless/until you really have to use a component in several 
> places or are publishing a library with one.
>
> For that project I linked to, I wanted to get a taste of developing 
> reusable components with Elm, even though the app was pretty small. I've 
> later refactored it to what I'd consider a more maintainable version and it 
> got considerably smaller and with less boilerplate (which makes it easier 
> to understand): 
> https://github.com/joakin/gimme-gif/commit/aa36b8237cd92835063ee5456d0c30dc39a4eb8d
>
> I'd recommend reading more about reuse too 
> https://guide.elm-lang.org/reuse/
>
>
> On Saturday, September 17, 2016 at 1:32:39 AM UTC+2, Matteo Giachino wrote:
>>
>> Hello everybody, I have a problem and I can't find a solution.
>>
>> The code consist in 3 modules. *Main*, *ItemList* and *Form*
>>
>> The *Main* is the glue and message broker of the app. The other two are 
>> a list and a form to update the list.
>>
>> The list has it's logic to fetch the results from an api, with all it's 
>> internal events that gets routed through the update function of *Main* 
>> with Cmd.map.
>> The form is exactly the same. With internal events to manage its state 
>> and an add button to trigger an HTTP POST request to update the database.
>>
>> Everything is great and separated. But the problem is the "ADD" button. 
>> When I press it, I want to perform a post, and on the form event 
>> UpdateSucceed I want to update the list!
>>
>> Here is the relevant code of Main.elm
>>
>> update : Msg -> Model -> ( Model, Cmd Msg )
>> update msg model =
>>     case msg of
>>         FormMsg formMsg ->
>>             let
>>                 ( updatedItem, formCmd ) =
>>                     Form.update formMsg model.newItem
>>             in
>>                 ( { model | newItem = updatedItem }
>>                 , Cmd.map FormMsg formCmd
>>                 )
>>
>>
>>         ItemListMsg itemListMsg ->
>>             let
>>                 ( updatedList, itemListCmd ) =
>>                     ItemList.update itemListMsg model.items
>>             in
>>                 ( { model | items = updatedList }
>>                 , Cmd.map ItemListMsg itemListCmd
>>                 )
>>
>> here is the update function of Form.elm
>>
>> update : Msg -> Item -> ( Item, Cmd Msg )
>> update msg model =
>>     case msg of
>>         ...
>>
>>
>>         Add ->
>>             ( model, doAddItem model )
>>
>>
>>         UpdateSucceed newItem ->
>>             ( initialModel, Cmd.none )
>>
>> I searched through the posts and everybody is suggesting to change the 
>> signature of the Form module update function, and return a third element, 
>> the outgoing message. I could go for it, but I really struggling to 
>> understand how to handle it in the Main update function, because one 
>> command is handled by the elm runtime on every message that arrives to 
>> update. I don't understand where I should manage this 2 different things to 
>> do when UpdateSucceed is triggered on the form. Re initialize the model in 
>> the form (clear the fields) and trigger an event that in some way gets 
>> routed through the Main module to the ItemList module.
>>
>> Any help is appreciated, this is a personal project, so I'm eager to 
>> learn the most elegant way to handle this situation, and refactoring is not 
>> a problem.
>>
>

-- 
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.

Reply via email to