Re: [elm-discuss] Re: How do I render a child component in 0.17 (like CounterList)?

2016-05-18 Thread Homan Chou
Interesting... it's like it's own module.  I feel like there are a lot of
little things like this that aren't covered in any of the getting started
guides.

On Wed, May 18, 2016 at 1:05 PM, Peter Damoc  wrote:

> It means that it exports both the type Dispatch and the tag Remove. It's
> explicit with what it exports.
> It should have been "Dispatch(..)" because in cases like this you might
> want to expose all the Dispatch Tags.
>
>
> On Wed, May 18, 2016 at 10:55 PM, Homan Chou  wrote:
>
>> Ah... thanks.  I read that wrong and thought you were linking the old
>> repo.
>>
>> What does "Dispatch(Remove)" mean in the Counter exposing part?
>>
>> On Tue, May 17, 2016 at 10:54 PM, Peter Damoc  wrote:
>>
>>> It works like you can see in the second link you've quoted. :)
>>>
>>>
>>>
>>>
>>> On Wed, May 18, 2016 at 8:40 AM, Homan Chou  wrote:
>>>
 Hi Brian,
> The Elm Architecture Tutorial has a "nesting" example:
> https://github.com/evancz/elm-architecture-tutorial/tree/master/nesting
> 
>
> If you worked with the previous elm-architecture-tutorial (the one
> with 8 examples) I have a port of that tutorial that you can consult to 
> see
> how some of those concepts translate to 0.17:
>
> https://github.com/pdamoc/elm-architecture-tutorial/tree/master/examples/4


 The new updated nesting tutorials don't include the modified "fancier"
 list of counters example where the delete button is in the child Counter
 component.  In the 0.16 example a "context" was passed in from the parent
 with some signal forwarding magic.  In a world where there are no signals
 in Elm now, how does this work?

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

>>>
>>>
>>>
>>> --
>>> There is NO FATE, we are the creators.
>>> blog: http://damoc.ro/
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Elm Discuss" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/elm-discuss/GZidxLFlLtQ/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> elm-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> 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.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/GZidxLFlLtQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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


Re: [elm-discuss] Re: Knowing if Dict has changed

2016-05-18 Thread Janis Voigtländer
In principle it’s correct. The type needs to be a bit different (comparable
instead of a). Moreover, it will still not work reliably if you call it
with something where the b type is itself a type that does not have
reliable ==. For example, if you call that dictEquals on a Dict Int (Set
Int), you can still be told that the things are unequal when actually they
are semantically equal.
​

2016-05-18 17:51 GMT+02:00 surfncode :

> Thanks. That would be great. Can other experts confirm it works ?
>
> Le mercredi 18 mai 2016 17:11:56 UTC+2, Max Goldstein a écrit :
>>
>> Sorry, posted too soon.
>>
>> dictEquals : Dict a b -> Dict a b -> Bool
>> dictEquals d1 d2 =
>>   d1 == d2 || Dict.toList d1 == Dict.toList d2
>>
>> This will short-circuit when the object references are the same and
>> otherwise do the work necessary to always give the correct answer. (I think
>> - please tell me if I'm wrong.)
>>
> --
> 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.
>

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


Re: [elm-discuss] [ANN] Elm Style Animation v 1.0.0 - Now with SVG animations

2016-05-18 Thread Peter Damoc
This is awesome!

I've updated the Dash docset to honor your release.
I can now report that there are some 106 packages that have already made
the transition to 0.17 :)


On Wed, May 18, 2016 at 12:21 AM, Matthew Griffith 
wrote:

>
> Hi All,
>
> I just released a fairly large update I've been working on.
>
> https://github.com/mdgriffith/elm-style-animation
>
> First off, elm-html-animation has been renamed* elm-style-animation*
> because it now covers SVG animations as well as html styles.
>
> This is for elm 0.17.  If you use this library and think you're going to
> be on 0.16 for a while, let me know and I'll see what I can do to provide a
> temporary 0.16 version.
>
> So what's new?
>
>- The syntax for specifying animations now is cleaner and more
>powerful.  You can use standard elm machinery like List.map and
>List.indexedMap to do things like stagger animations or animate a list of
>things.  This is much better than before.
>- Native support for Elm's Color type.
>- SVG attributes can now be animated!
>- You can morph polygons into each other
>.
>- You can morph batman logos into each other.
> Cause
>this is what you really wanted to do with elm.
>- The flowermenu
> from
>before is now even cleaner
>
>
>
>
>
>
>
>
>
> --
> 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.
>



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


Re: [elm-discuss] Re: How to implement wrapping components in elm

2016-05-18 Thread Daniel Kwiecinski
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  > 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" 

Re: [elm-discuss] Re: How to implement wrapping components in elm

2016-05-18 Thread Peter Damoc
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.kwiecin...@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 > > 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 

Re: [elm-discuss] Re: How to implement wrapping components in elm

2016-05-18 Thread Yosuke Torii
Oh, it looks just nesting views (I'm not familiar with ClojureScript
though). If so, the solution is much simpler. Like this:

```
container : List (Html msg) -> Html msg
container children =
  div
[  style [ ("padding", "20px") ] ]
children
```

full version


Isn't it working for you? I often use this pattern for popup.


2016-05-18 19:15 GMT+09:00 Daniel Kwiecinski :

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

Re: [elm-discuss] Re: How to implement wrapping components in elm

2016-05-18 Thread Daniel Kwiecinski
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  > 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 

[elm-discuss] Re: Pong example in Elm 0.17

2016-05-18 Thread Wil C
The mario example in 0.17

https://gist.github.com/pdamoc/6f7aa2d3774e5af58ebeba369637c228

On Thursday, May 12, 2016 at 12:59:13 AM UTC-7, Sean Seefried wrote:
>
> Hi all,
>
> I just started using Elm about 2 weeks ago. I had a lot of fun playing 
> with the Pong example and even started making my own game in Elm. I'm a 
> long time Haskell programmer and since Elm is very Haskell-like I've found 
> it very easy to use.
>
> Then Elm 0.17 came out and suddenly Signals are gone. "No problem", I 
> thought, "I'll just look at how Pong is implemented now and update my game".
>
> But then I discovered that the Pong example is now gone. So I decided to 
> look through the new libraries to see how graphics were done now ... and 
> discovered that I couldn't find how to do HTML Canvas-style graphics 
> anymore.
>
> So, my two questions are:
>
> 1. Is the Pong example being rewritten in Elm?
> 2. How do I do HTML canvas-style graphics now? 
>
> Cheers,
>
> Sean
>
> p.s. Please don't take the tone of this post the wrong way. I'm very happy 
> to keep up with Elm as it evolves. I just want to know how to reimplement 
> my game as quickly as possible! :-) 
>

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


Re: [elm-discuss] Re: How to implement wrapping components in elm

2016-05-18 Thread Peter Damoc
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.kwiecin...@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 > > 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 
 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