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.
