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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to