Any plans to update elm-mdl and elm-parts to 0.17? On Thursday, 19 May 2016 07:32:23 UTC+1, debois wrote: > > As I understand it, you want to write a function which takes a list of TEA > components, then wires up and renders those. As Peter pointed out, this can > be done when your "components" are really just view functions. If they are > actual TEA components, each with (view, update, Model, Message, > Subscription), there's a problem in that you'll need, someplace, a type > that can host "Model" for any such component. I don't think Elm has such a > type. > > I wrote a library for treating TEA-components uniformly ( > https://github.com/debois/elm-parts); elm-mdl uses that. It gets most of > the way, but in the end, to use it, you have to make a record that contains > every type of Model you are treating. Elm-mdl does it like so: > https://github.com/debois/elm-mdl/blob/master/src/Material.elm#L178-L190. > > I wrote a blog post about how this is achieved: > https://medium.com/@debois/elm-components-3d9c00c6c612#.x5mtskkmg. (It's > phrased in 0.16 terms, though.) > > > > On Wednesday, May 18, 2016 at 6:38:45 PM UTC+2, Daniel Kwiecinski wrote: >> >> Hi Peter, >> >> Just skimmed on the gist, but can already tell this is great help. >> Many thanks for your work. >> >> Cheers, >> Dan >> >> On Wednesday, 18 May 2016 15:20:38 UTC+1, Peter Damoc wrote: >>> >>> This gist (previously posted) >>> https://gist.github.com/pdamoc/aef6306a9001de109aeece37e5627d06 >>> is a kind of minimalist example. It shows how to join together 2 >>> different widgets (RandomGif and Counter). >>> The process for extending the list with new widgets is mechanical, just >>> add options to all the relevant types. >>> >>> >>> >>> >>> >>> On Wed, May 18, 2016 at 4:59 PM, Daniel Kwiecinski < >>> [email protected]> wrote: >>> >>>> Sounds very promising. Could you please provide minimalist example? >>>> >>>> On Wednesday, 18 May 2016 13:47:16 UTC+1, Peter Damoc wrote: >>>>> >>>>> You just use regular Elm Architecture and compose the model of the >>>>> autocomplete into the proper place, same with update and view. >>>>> >>>>> To speak in React terms, what you had above are components that have >>>>> only props. These can be implemented with simple functions in Elm. >>>>> >>>>> If a component needs state and rest calls, it needs to follow the Elm >>>>> Architecture. Please note that the component can be fully encapsulated in >>>>> a >>>>> module. The kind of boilerplate needed for state management is very small >>>>> and very predictable. You can even extract it into some kind of Widget >>>>> abstraction and have all the Widgets be updated by a single line of code. >>>>> :) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, May 18, 2016 at 3:16 PM, Daniel Kwiecinski < >>>>> [email protected]> wrote: >>>>> >>>>>> This is fine. Big thanks for your effort. >>>>>> But, how about instead of components being simple functions we have >>>>>> components as {init, update, view, subscription} so they encapsulate >>>>>> their >>>>>> logic. >>>>>> Think in having a component similar to google places autocomplete. >>>>>> From it's parent we still want to pass a configuration to it and react >>>>>> to >>>>>> the commands coming from the autocomplete (such as place changed) but we >>>>>> do >>>>>> not want or need to interfere with the autocomplete component internal >>>>>> state, rest calls etc? >>>>>> >>>>>> On Wednesday, 18 May 2016 13:08:21 UTC+1, Peter Damoc wrote: >>>>>>> >>>>>>> Oh, that's much easier: >>>>>>> >>>>>>> import Html exposing (..) >>>>>>> import Html.Attributes exposing (class) >>>>>>> >>>>>>> helloComponent name = >>>>>>> p [] [text ("Hello, " ++ name ++ "!")] >>>>>>> >>>>>>> sayHello = >>>>>>> helloComponent "world" >>>>>>> >>>>>>> >>>>>>> listHello names = >>>>>>> div [] (List.map helloComponent names) >>>>>>> >>>>>>> >>>>>>> -- GENERIC WRAPPING COMPONENT >>>>>>> >>>>>>> wrapComponents components = >>>>>>> div [class "components-wrapped-in-pages-so-we-can-swipe-them"] >>>>>>> (List.map (\c -> div [class "page"] [c]) components) >>>>>>> >>>>>>> >>>>>>> names = ["Jim", "Bill", "Joe"] >>>>>>> >>>>>>> >>>>>>> main = >>>>>>> wrapComponents >>>>>>> [ sayHello >>>>>>> , helloComponent "Sandra" >>>>>>> , listHello names >>>>>>> ] >>>>>>> >>>>>>> There is no Signal anymore in Elm and if you use The Elm >>>>>>> Architecture, all you get is regular values. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, May 18, 2016 at 1:15 PM, Daniel Kwiecinski < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Here is a sketch of how it would look like in reagent >>>>>>>> (ClojureScript) >>>>>>>> >>>>>>>> >>>>>>>> ; -- SOME CONCRETE COMPONENTS >>>>>>>> >>>>>>>> ; a component taking a String as a model >>>>>>>> (defn hello-component [name] >>>>>>>> [:p "Hello, " name "!"]) >>>>>>>> >>>>>>>> ; a stateless component using another component >>>>>>>> (defn say-hello [] >>>>>>>> [hello-component "world"]) >>>>>>>> >>>>>>>> ; a component taking a ratom (it's a signal in elm speak) as a model >>>>>>>> (defn reactive-hello-component [name] >>>>>>>> [:p "Hello, " @name "!"]) >>>>>>>> >>>>>>>> ; a component taking list of Strings as a model >>>>>>>> (defn list-hellos [names] >>>>>>>> (for [n names] >>>>>>>> [hello-component (str "hello " n)])) >>>>>>>> >>>>>>>> ; -- GENERIC WRAPPING COMPONENT >>>>>>>> >>>>>>>> >>>>>>>> ; a wrapping components. take list of components as a parameter and >>>>>>>> wraps them in pages >>>>>>>> (defn wrap-components [components] >>>>>>>> (fn [] >>>>>>>> [:div {:class >>>>>>>> "components-wrapped-in-pages-so-we-can-swipe-them"} >>>>>>>> (for [c components] >>>>>>>> [:div {:class "page"} c])])) >>>>>>>> >>>>>>>> >>>>>>>> ; -- MAIN VIEW GLUING ALL TOGETHER >>>>>>>> >>>>>>>> >>>>>>>> (defn main-view [] >>>>>>>> (let [reactive-name (ratom "initial-name") >>>>>>>> input-state (ratom "")] >>>>>>>> [:div {:class "some-boilerplate"} >>>>>>>> >>>>>>>> ; the two lines below are not following re-frame pattern. >>>>>>>> There are there just to express I have the state which changes. >>>>>>>> [:input {:onchange (fn [value] (!reset input-state >>>>>>>> value))}] ; react to inout changes and pass the value to model (in >>>>>>>> re-frame instead of directly updating the model we would send a signal >>>>>>>> (as in elm) and have subscription react to the signal but for >>>>>>>> simplicity I ommit the patern) >>>>>>>> [:button {:onclick #(!reset reactive-name @input-state)}] >>>>>>>> ; copy the states on button click >>>>>>>> >>>>>>>> [:span {:class >>>>>>>> "here-come-generic-swipe-able-pages-wrapping-any-components"} >>>>>>>> >>>>>>>> ; here is the usage of the wrapping container >>>>>>>> (wrap-components [ >>>>>>>> say-hello ; stateless component >>>>>>>> #(hello-component "some-fancy-name") ; >>>>>>>> #(...) is lambda in clojure, here we close over some static state >>>>>>>> #(reactive-hello-component >>>>>>>> reactive-name) ; #(...) here we close over some reactive state, so the >>>>>>>> component re-renders when the model (state) changes >>>>>>>> #(list-hellos ["a" "b" "c"]) ; >>>>>>>> component taking list as a state (model) >>>>>>>> ])]])) >>>>>>>> >>>>>>>> ; -- MOUNT VIEW TO DOM >>>>>>>> >>>>>>>> ; bind the main-view to DOM and start observing deltas to render if >>>>>>>> needed >>>>>>>> (defn ^:export run [] >>>>>>>> (r/render [main-view] (js/document.body))) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wednesday, 18 May 2016 08:42:45 UTC+1, Peter Damoc wrote: >>>>>>>>> >>>>>>>>> Can you mock some code that would show how would you like to use >>>>>>>>> this? >>>>>>>>> Imagine that it is already implemented in some library and write >>>>>>>>> against that imaginary library. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, May 17, 2016 at 5:36 PM, Daniel Kwiecinski < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> The problem is that the generic container component (Let's call >>>>>>>>>> it C) do not know about it potential children (let's call them X, Y, >>>>>>>>>> Z) . >>>>>>>>>> There is top level component (Let's call it T) which has a knowledge >>>>>>>>>> about >>>>>>>>>> all of them (it is the app). The C is in self contained package, you >>>>>>>>>> can >>>>>>>>>> consider it to implement material design list view. How Can I >>>>>>>>>> implement C >>>>>>>>>> so T can use T with X, Y, Z ? >>>>>>>>>> >>>>>>>>>> On Tuesday, 17 May 2016 15:09:36 UTC+1, Peter Damoc wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Daniel, >>>>>>>>>>> >>>>>>>>>>> If you have a limited number of components you can unify them >>>>>>>>>>> into one kind of a component. >>>>>>>>>>> >>>>>>>>>>> Here is a self contained example that unifies Counter and >>>>>>>>>>> RandomGif and then uses them in a single list. >>>>>>>>>>> https://gist.github.com/pdamoc/aef6306a9001de109aeece37e5627d06 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, May 17, 2016 at 3:47 PM, Daniel Kwiecinski < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> So let me expand my scenario a little bit. Lets assume that the >>>>>>>>>>>> CounterList component is very feature heavy. It makes lots of work >>>>>>>>>>>> to >>>>>>>>>>>> layout its children, manages drag to sort or whatever fancy stuff >>>>>>>>>>>> you can >>>>>>>>>>>> imagine. Now in my app I have many instances of usage of >>>>>>>>>>>> CounterList and I >>>>>>>>>>>> want to apply the complex behaviour not only to counters but also >>>>>>>>>>>> to gif >>>>>>>>>>>> and to mixed counters with gifs and many many other possible >>>>>>>>>>>> configurations >>>>>>>>>>>> (think in hundreds). I don't really want to implement dedicated >>>>>>>>>>>> CounterList, GifList, 2GifsWith3CountersList and other few >>>>>>>>>>>> hundreds >>>>>>>>>>>> SomethingBlaBlaList. >>>>>>>>>>>> Is it possible in elm at all? If yes how so? >>>>>>>>>>>> >>>>>>>>>>>> P.S. It is not imaginary question. I try to port existing >>>>>>>>>>>> application implemented in Re-Frame (ClojureScript framework) in >>>>>>>>>>>> which this >>>>>>>>>>>> scenario is trivial. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tuesday, 17 May 2016 13:33:27 UTC+1, Wil C wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Daniel, >>>>>>>>>>>>> >>>>>>>>>>>>> I think normally, you don't. I think the constraint here is >>>>>>>>>>>>> that you need to explicitly set the types of each of the >>>>>>>>>>>>> sub-components for >>>>>>>>>>>>> every component that you make for a page. In the example that you >>>>>>>>>>>>> give, >>>>>>>>>>>>> you'd actually need to create 4 types of components: TopLevel, >>>>>>>>>>>>> Counter, >>>>>>>>>>>>> CounterList, and Gif. >>>>>>>>>>>>> >>>>>>>>>>>>> TopLevel component would include CounterList and Gif. And then >>>>>>>>>>>>> CounterList would contain Counters. It is CounterList's job to >>>>>>>>>>>>> dynamically >>>>>>>>>>>>> keep track of the number of Counters. That way, you don't need a >>>>>>>>>>>>> generic >>>>>>>>>>>>> component to contain an unknown number of things with unknown >>>>>>>>>>>>> types. And >>>>>>>>>>>>> then if those components need to talk to each other (Like once >>>>>>>>>>>>> you add 5 or >>>>>>>>>>>>> more counters, you see a funny cat gif), I believe you can send >>>>>>>>>>>>> messages >>>>>>>>>>>>> through Cmds (in 0.17) or Effects (in <0.17). >>>>>>>>>>>>> >>>>>>>>>>>>> With the hierarchical thinking of laying out components, I >>>>>>>>>>>>> found that Thinking in React >>>>>>>>>>>>> <https://facebook.github.io/react/docs/thinking-in-react.html> >>>>>>>>>>>>> helps. >>>>>>>>>>>>> >>>>>>>>>>>>> If you find that you really need the flexibility of having >>>>>>>>>>>>> different components in a container, it's doable. But it comes at >>>>>>>>>>>>> a cost. >>>>>>>>>>>>> Generally, if you're making a web app of some sort, it's not >>>>>>>>>>>>> needed. I >>>>>>>>>>>>> cover entity component systems recently in another thread, and >>>>>>>>>>>>> it's for >>>>>>>>>>>>> games. >>>>>>>>>>>>> >>>>>>>>>>>>> https://groups.google.com/forum/#!topic/elm-discuss/c9MhBzVPbr8 >>>>>>>>>>>>> >>>>>>>>>>>>> Wil >>>>>>>>>>>>> >>>>>>>>>>>>> On Tuesday, May 17, 2016 at 5:13:56 AM UTC-7, Daniel >>>>>>>>>>>>> Kwiecinski wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Elmers, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here is my scenario. Say I have Main.elm which defines main >>>>>>>>>>>>>> view form my application. I also have bunch of other components >>>>>>>>>>>>>> (with their >>>>>>>>>>>>>> corresponding model and message types) say Counter and Gif. >>>>>>>>>>>>>> ( >>>>>>>>>>>>>> https://github.com/evancz/elm-architecture-tutorial/blob/master/nesting/Gif.elm >>>>>>>>>>>>>> ) >>>>>>>>>>>>>> ( >>>>>>>>>>>>>> https://github.com/evancz/elm-architecture-tutorial/blob/master/nesting/Counter.elm >>>>>>>>>>>>>> ) >>>>>>>>>>>>>> Now I'd like to create new generic component which as a >>>>>>>>>>>>>> parameter (initial value of its model?) takes list of any type >>>>>>>>>>>>>> of component >>>>>>>>>>>>>> (say two counters, then one gif and another three counters) and >>>>>>>>>>>>>> wraps them >>>>>>>>>>>>>> into some decorating html. >>>>>>>>>>>>>> The scenario serves as a illustration of the question, how do >>>>>>>>>>>>>> I implement components which can wrap lists of arbitrary >>>>>>>>>>>>>> component types. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Daniel >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> There is NO FATE, we are the creators. >>>>>>>>>>> blog: http://damoc.ro/ >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> There is NO FATE, we are the creators. >>>>>>>>> blog: http://damoc.ro/ >>>>>>>>> >>>>>>>> -- >>>>>>>> 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. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> There is NO FATE, we are the creators. >>>>>>> blog: http://damoc.ro/ >>>>>>> >>>>>> -- >>>>>> 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. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> There is NO FATE, we are the creators. >>>>> blog: http://damoc.ro/ >>>>> >>>> -- >>>> 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. >>>> >>> >>> >>> >>> -- >>> There is NO FATE, we are the creators. >>> blog: http://damoc.ro/ >>> >>
-- 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.
