Hi, Is there a component that can simulate an accordion?
On Wednesday, August 3, 2016 at 6:07:00 PM UTC-4, debois wrote:
>
> Dear all,
>
> I'm very happy to announce the release of elm-mdl 7.0.0. This release
> marks a substantial achievement of elm-mdl: we have now ported *every*
> component
The most important one I keep coming back to is the design principle of
rigorously separating functions and data - don't keep functions in your
model, etc.
In many ways I jumped on Elm just because it felt so immediately *right*
and natural, as opposed to "I heard Elm was great but now I have
Yes, that's why I said back to square one if Cmd.batch isn't ordered. The
only thing this is guaranteeing (and the only intended guarantee) is that
the messages which only update the model are separated from the ones which
cause effects. The ones which cause effects produce ones which update
Actually, I'd probably use a List instead of Maybe on the immediately
returned event(s).
doSideEffects : Act -> Model -> (List Evt, Cmd Evt)
doSideEffects act model =
case act of
UpdateCustomer customer ->
( [ CustomerUpdateRequested ]
, callServerWithCustomer customer
)
So you really are wanting to hard device events into two different ones,
those that can *only* alter the model, and those that can *only* send
commands (which may call ones that alter the model). Unsure if it might
actually happen but might have to take into account possible race
conditions
My mistake, SubmitCustomerChanges was supposed to be UpdateCustomer above.
On Thursday, August 11, 2016 at 3:16:12 PM UTC-5, Kasey Speakman wrote:
>
> Oh! What I was doing in my examples was pretending there was a version of
> Elm that natively supported `command` and `update` methods instead of
Oh! What I was doing in my examples was pretending there was a version of
Elm that natively supported `command` and `update` methods instead of just
`update`. I was exploring what that could look like, how it would affect
things.
I don't have a complete example in mind. The original post was
Can you supply a complete example of what you want it to look like
(excepting view, we don't care about view right now).?
On Thursday, August 11, 2016 at 1:25:38 PM UTC-6, OvermindDL1 wrote:
>
> In this case it is just filling in for 'something' that can dispatch some
> messages to `update`
In this case it is just filling in for 'something' that can dispatch some
messages to `update` and dispatch commands to `command`. I'm not sure how
to dispatch those without some dispatcher that is already acting like the
existing update...
On Thursday, August 11, 2016 at 1:21:42 PM UTC-6,
I'm not sure I like it either. Seems like a lot of UI commands would just
be auto-converted to events by `command`.
However, in your example, I'm not sure what your filter code is about (my
ignorance). If I am understanding it right, it's filling in for the case
when you need to respond to an
Yeah I was playing with the idea for more message types though still not
convinced yet. Let's go hog-wild for a second to see how it would look
with a fairly major overhaul and multiple message types though:
```elm
{-| Msg is used for global message dispatching, handled only by the `filters`
I guess what you are proposing is separating a Message into a 'commands'
and 'update' callbacks? That could work well too... I could add that as
an option to my ProgramEx testing library (where I test with extra
callbacks) if you want to play around with it? Do you propose that
`update`
Heh, yes I keep putting different ideas here, I am not focusing on a single
idea, just working with the API's in testing a bit, figure out some new
ideas, and document them here, upon which I then go out, make a mock-up of
the ideas, and see how it works and document the results again. Just a
You throw in a lot of different ideas. I’m getting confused.
Concerning the approach with having both subscriptions and your new filters
hook, I still think what I wrote in my last message (about the case if you
were to make the same decisions as the original code about which
subscriptions are
the two themes I learned were:
simplicity & accuracy
simplicity: fewer concepts to learn than most languages
accuracy: following on from simplicity, lack of 'features' to shoot
yourself in the foot, leads to type checking and guarantee goodness
On Thu, 11 Aug 2016 at 16:59 Leroy Campbell
I'd say learning how to make illegal states unrepresentable.
https://vimeo.com/162036084
--
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
MDL is a mostly-javascript-driven-with-css helpers for the complicated
Material stuff, for the rest of it you can do whatever you want, including
using elm-html (elm-mdl is designed to add to elm-html, not replace it).
On Wednesday, August 10, 2016 at 9:58:58 PM UTC-6, David Legard wrote:
>
>
Hi
I am asking why* type alias* instead of just *type*, to declare record.
type X
= T1
| T2
type alias X1 =
X
*-- why not just type here*
type alias Y =
{ a : Int
, b : Int
}
type alias Y1 =
Y
Samples:
a1 : X -- Ok
a2 : X1 -- Ok
a3 : T1 |
Immutability
On Thursday, August 11, 2016 at 2:37:33 PM UTC+5:30, Peter Damoc wrote:
>
> "The fundamental fact about learning: Anything is easy if you can
> assimilate it to your collection of models. If you can't, anything can be
> painfully difficult.” - Seymour Papert
>
> I'm trying to come
Not so much Elm itself, but functional programming in general.
What wouldn't lodge into my thinking was: immutability + the complete lack
of variables + and no global scope.
How do you achieve stuff if you can't write x = x + 1 ?
It took me ages to get comfortable with the functional way of
"The fundamental fact about learning: Anything is easy if you can
assimilate it to your collection of models. If you can't, anything can be
painfully difficult.” - Seymour Papert
I'm trying to come up with a sorted list of concepts and models that a
prospective Elm user needs to learn in order
21 matches
Mail list logo
