They both have been already: http://package.elm-lang.org/packages/debois/elm-mdl/4.0.0/ http://package.elm-lang.org/packages/debois/elm-parts/2.0.0/
On Thursday, May 19, 2016 at 11:27:46 AM UTC+2, Daniel Kwiecinski wrote: > > 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 < >>>> daniel.k...@gmail.com> 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 < >>>>>> daniel.k...@gmail.com> 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 < >>>>>>>> daniel.k...@gmail.com> 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 < >>>>>>>>>> daniel.k...@gmail.com> 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 < >>>>>>>>>>>> daniel.k...@gmail.com> 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 elm-discuss...@googlegroups.com. >>>>>>>>>>>>> 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 elm-discuss...@googlegroups.com. >>>>>>>>>>> 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 elm-discuss...@googlegroups.com. >>>>>>>>> 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 elm-discuss...@googlegroups.com. >>>>>>> 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 elm-discuss...@googlegroups.com. >>>>> 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
