[elm-discuss] Re: elm-outdated

[Vlad GURDIGA]

Yeah I find it useful, thank you!  

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

[elm-discuss] On Intl/CLDR

[Vlad GURDIGA]

Hey everybody! 

The other day I found myself writing a function to format numbers 
.
 
The first question was: What is the right way to format a number? There 
should be a standard or something. 樂 Googled a bit and found about the 
Unicode CLDR Project . They have a huge amount of 
structured data, and I surely found the data I was looking for. 邏

Now, seeing all that data, I thought: Wow! Wouldn’t it be cool to have an 
Elm library that’l hold all that? elm-cldr?  Oh, it’d be enormous… What 
if I only need number formatting? Oh, I know: elm-cldr-numbers! 
and elm-cldr-dates! and elm-cldr-localenames! and… Ooooh yeah!! 鸞

Then I remember that the CLDR website was saying that they provide data for 
apps and operating systems. Hm… shouldn’t it be there already somewhere in 
the OS? 樂 Googled a bit more and found that browsers already have that as 
window.Intl 

 and 
MDN says it has quite good support, down to IE11. Couldn’t believe that 
one, so spun up my Windows VM and pasted a snippet into IE11’s console: it 
worked! 

Hm… OK… Now, it’d really be quite cool to build all those elm-cldr-* things 
that I imagined, wouldn’t it make more sense to reuse what’s already there? 
What would it be like to use that? OK, let’s go native! A couple hours 
later I got myself Native.Intl 
.
 


Now, looking at all this I begun wondering what would it be like to have it 
in the Elm standard library, and inevitably found Evan’s 2 threads (one 
 and two 
) about the 
philosophy around native in Elm, and I kind of see his point about keeping 
Elm high-quality, but how about cases like this where we’re not talking 
about JS libraries but about browser’s native APIs like Intl? 樂

It’d probably be not that hard to get that data 
 packaged into a few Elm 
libraries, hopefully not-that-large each, but it’d still end up growing the 
final app bundles, and probably some compilation time during the hundreds 
of refreshes a day that a dev does… So I’m not entirely sure it’s a 
constructive idea. 

So although for my little toy-project I can just use Elm native, how about 
long-term? What would make more sense? I mean these two options:

   1. implement Elm libraries using the CLDR data 
   
   2. hope that window.Intl will some day become part of Elm standard 
   library

What are some pros and cons? Are there any other options people have 
considered? 樂

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

[elm-discuss] Re: Elm Language Server - Document and repository to coordinate and capture requirements effort

[Vlad GURDIGA]

This seems a lot like the thing that I have found unusually useful in 
TypeScript land: tsserver 
.
 
Looking at that case, it seems like a language server would make for much 
more streamlined efforts around the language tooling, IMHO. 樂

Just my little 2¢. 邏

-- 
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] Strange compiler error - cannot find a field that is obviously there.

[Vlad GURDIGA]

Hey Rupert! 

If I try to pull out just an isolated example to make an SSCCE out of... 
> the problem goes away.


Hm… this is interesting! 樂

I’m wondering what are other factors that could lead to that issue, which 
you have in the production context but not in SSCCE?

I haven’t seen mentioned your environment: Elm version? Operating System? 
The IDE or text editor? Could you please enumerate those? 邏

-- 
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] Elm with one message

[Vlad GURDIGA]

Hey everybody!

Looking back on this thread, it looks like there are two major issues that 
were brought up: 樂

   1. unintended state pre-computation in case of onClick handlers;
   2. accidental resurrection of the pieces of state captured in closures.

>From my understanding, it seems like (2.) is not directly related to my 
mostly-messageless approach I initially presented here, and can also happen 
with the standard TEA, so it’s more like something to keep in mind than 
something that is immediately fixable in my code. Noted. ✍️

The (1.) though, seems directly related to my mostly-messageless approach. 
As Peter pointed out, it will get more problematic as the state grows, and 
I wanted to solve it. The solution that Peter proposed was to re-introduce 
messages and update functions, which would have solved the problem by 
moving the state computation to the update function, and so deferring it 
until the click actually happens, as appropriate per TEA. I’ve tried that 
 (to best of my understanding), 
but compared with the mostly-messageless approach, it seems like the amount 
of indirection and code required by messages and update function does not 
justify itself. 樂

One other thought that crossed my mind during this conversation — regarding 
the state pre-computation issue — was to have the onClick callback be an 
actual function that can be invoked when the click happens. The thing 
though, is that because onClick doesn’t have a value to yield, its callback 
is basically a zero-argument function, and so is evaluated immediately — 
which is actually the essence of the issue. 

I worked around that by re-implementing onClick 

 to 
accept a one-argument function instead: 邏

onClick : (String -> msg) -> Html.Attribute msgonClick callback =
Html.Events.on "click" (Json.Decode.map callback Html.Events.targetValue)


…even though the callback argument (an empty string) ends up ignored 
.
 
邏

Problem solved!  

-- 
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] Elm with one message

[Vlad GURDIGA]

Thank you Peter! 邏

The third option that you proposed 

 
seems to fit nicer with the shape of my data: multiple nested records. I’ve 
tried it, and, I got something compiling!  
https://github.com/gurdiga/xo.elm/pull/1.

So now my child-module exposes additionally its Msg and its update 
function, which the parent-module uses to wire it up in its own fabric.

Does this look close to what you had in mind? 樂

-- 
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] Elm with one message

[Vlad GURDIGA]

So… 樂

I’m adding adding a couple of buttons this morning, and I feel I’m worried 
about that thing that Peter mentioned 
: 
Whenever I have an onClick with a callback instead of message I basically 
pre-compute the after-click state. I think I understand the issue, and I’d 
like to do it The Right Way®. 

In my app I have a large data entry form where initial fields determine 
which subsequent fields will be. It’s my understanding that every change to 
the model should be its own message. So far I have 50 fields in total (and 
there will probably be more) — does this mean that I need to have 50 things 
in my Msg? Or am I seeing it 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.

Re: [elm-discuss] Elm with one message

[Vlad GURDIGA]

Hm… OK, noted. 樂

On Friday, September 1, 2017 at 11:08:25 AM UTC+3, Michael Jones wrote:
>
> "The recommendation is to keep Models and Msg as pure data." 
>
> Sound advice. I think that one trouble with passing functions around in 
> messages is that as they get more complex you stand a bigger & bigger 
> chance of closing over some other state and then you're back to the problem 
> of passing stale chunks of state around in your messages and it would be 
> enormously tricky to track down. 
>   
>

-- 
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] Elm with one message

[Vlad GURDIGA]

Oh wow! This looks super cool! 邏

…and it seems this would also cover for the issue that Peter mentioned 
<https://groups.google.com/d/msg/elm-discuss/ta64y4JBMc4/Y8PEUFDPCgAJ>: 
this gives me the ability to have a real onClick callback without 
pre-computing the expected-after-click state! 鸞 — Right Peter? 樂

OK, this is good. I’m not sure if I want to completely move to this model 
right away — although Elm makes it easy to refactor in any way imaginable 
 — but it’s definitely useful to have it under my belt. 邏

Thank you Mark! 

On Thursday, August 31, 2017 at 10:29:18 PM UTC+3, Mark Hamburg wrote:
>
> Your previous update structure was essentially (ignoring commands and 
> subscriptions)
>
> type Msg
> = Set Model
>
> update : Msg -> Model -> Model
> update (Set newModel) model =
> newModel
>
>
> used as something like:
>
> ... onClick (Set { model | counter = model.counter + 1 }) ...
>
>
> The revised approach looks like:
>
> type Msg
> = Apply (Model -> Model)
>
> update : Msg -> Model -> Model
> update (Apply fn) model =
> fn model
>
>
> used as:
>
> ... onClick (Apply (\model -> { model | counter = model.counter + 1 })) ...
>
>
> The point is that we avoid capturing the model value in the message being 
> routed around so that we can interleave this message with other 
> asynchronous responses.
>
> Again, as noted in my earlier message, this is not the Elm way and will be 
> unfriendly to tools like the debugger but it is valid Elm. It is somewhat 
> more complicated than the original version but still avoids the level of 
> indirection associated with messages. It is also more efficient than the 
> original form in that it at most constructs new function closures rather 
> than constructing entire new model values for each possible action in the 
> UX.
>
> Mark
>
> P.S. I was tempted to also include this form in the example:
>
> ... onClick (Apply incrementCounter) ...
>
> incrementCounter : Model -> Model
> incrementCounter model =
> { model | counter = model.counter + 1 }
>
> But if one did that, one might as well have an IncrementCounter message 
> and handle it in the update function.
>
>
>
> On Thu, Aug 31, 2017 at 11:57 AM, Vlad GURDIGA <gur...@gmail.com 
> > wrote:
>
>>
>> On Monday, August 28, 2017 at 4:01:20 AM UTC+3, Mark Hamburg wrote:
>>>
>>> One other note: If you don't care about Reactor and the Debugger but do 
>>> care about async problems, you could get almost the same structure by 
>>> passing back Model -> Model functions instead of Model values.
>>>
>>
>> Sorry Mark, this sounds cool, but I’m kind of a slow thinker (generally) 
>> — could you give some pseudo-code to show an example of what you mean? 
>>  
>>
>>> Doing so may cause you to receive a visit from the Elm thought police 
>>> but it is entirely semantically viable within Elm (and it's what I could 
>>> imagine a lot of other functional languages doing by default).
>>>
>>> Mark
>>>
>> -- 
>> 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.
>>
>
>

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

[elm-discuss] Re: Elm with one message

[Vlad GURDIGA]

This would probably come in handy later, but for now I really enjoy having 
elm-make as my only build step. 邏

On Monday, August 28, 2017 at 4:28:03 PM UTC+3, Robin Heggelund Hansen 
wrote:
>
> You can use the Elm debugger just fine with, say, webpack. Just pass in 
> the `debugger: true` flag and you're good to go.
>

-- 
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] Elm with one message

[Vlad GURDIGA]

On Monday, August 28, 2017 at 4:01:20 AM UTC+3, Mark Hamburg wrote:
>
> One other note: If you don't care about Reactor and the Debugger but do 
> care about async problems, you could get almost the same structure by 
> passing back Model -> Model functions instead of Model values.
>

Sorry Mark, this sounds cool, but I’m kind of a slow thinker (generally) — 
could you give some pseudo-code to show an example of what you mean? 
 

> Doing so may cause you to receive a visit from the Elm thought police but 
> it is entirely semantically viable within Elm (and it's what I could 
> imagine a lot of other functional languages doing by default).
>
> Mark
>

-- 
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] Elm with one message

[Vlad GURDIGA]

Ooooh! …now I understand. 樂

There was this question looping into the back of my mind regarding onClick 
callbacks: “How do I get a zero-argument function in Elm?” and your 
explanation clarifies it — there can’t be a zero-argument function in Elm! 
Right? 

I’m surely curious about the philosophical implication of this, but even 
without them I’m happy to have this clarified. 邏

Thank you!

On Sunday, August 27, 2017 at 7:13:18 PM UTC+3, Peter Damoc wrote:
>
>
>
> On Sun, Aug 27, 2017 at 11:15 AM, Vlad GURDIGA <gur...@gmail.com 
> > wrote:
>>
>> You basically have to computer all the possible future states of the app.
>>>
>>
>> Not sure what you mean here. Could you please expand, or maybe point to 
>> an example in the code? 樂 
>>
>
> Let's simply the problem space and imagine that you have 3 buttons that 
> when clicked do some serious computation on the model. 
>
> With a traditional approach you have the message sent by one of the 
> buttons and the specific computation done in response to the message. 
>
> With this approach, you would have to compute all 3 heavy computation and 
> send the new state with the message.  If your main message is: 
>
> type Msg
> = Update Model
>
> then the 3 messages you will have to use on `onClick` would be equivalent 
> to:
>
> div []
> [ button [onClick (Update (doTheUpdateForMessageOne oldModel))] [text 
> "Do First Thing"] 
> , button [onClick (Update (doTheUpdateForMessageTwo oldModel))] [text 
> "Do Second Thing"] 
> , button [onClick (Update (doTheUpdateForMessageThree oldModel))] 
> [text "Do Third Thing"] 
> ]
>
> Or, more realistically, inside a child component with its own `update`, 
> have something like: 
>
> view onUpdate model = 
> let 
> toMsg msg = onUpdate (update msg model) 
> in 
> div []
> [ button [onClick (toMsg First)] [text "Do First Thing"] 
> , button [onClick (toMsg Second)] [text "Do Second Thing"] 
> , button [onClick (toMsg Third)] [text "Do Third Thing"] 
> ]
>
> this means that by the time the view is rendered, all 3 future states of 
> the that component have been computed.
> This is not a big issue if computing all future states is trivial (e.g. 
> one toggle state of some drawer) so it's fine for small widgets but if you 
> scale this to the level of the entire app, you might run into performance 
> issues. 
>
 

-- 
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] Elm with one message

[Vlad GURDIGA]

Hey Michael! 

Thank you for chipping in! 邏

On Friday, August 25, 2017 at 11:42:55 AM UTC+3, Michael Jones wrote:
>
> I can second Mark's point. At my company we had a little experiment where 
> chunks of state where sent in the messages. Not the whole model but not a 
> single unit either. It seemed really promising for a moment and quite clean 
> but then we started getting bugs which were very hard to understand. Turned 
> out to be exactly what Mark suggested. Between messages and commands we'd 
> have multiple copies of the same chunk of state in flight, each based on 
> some original value but each ignorant of the changes that the other were 
> representing. The end result was to just get the last state and lose 
> anything associated with other messages or commands happening around the 
> same time.
>
> We moved back to the standard strategy and all is well. 
>

So — just to check my understanding — the standard strategy is to only send 
enough bits of data with the message to describe the change that the update 
function needed to carry on, an not the actual changed bits of state. Am I 
close? 樂

-- 
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] Elm with one message

[Vlad GURDIGA]

Hey Mark! 

Thank you for taking time to look into this! 邏

On Thursday, August 24, 2017 at 7:18:44 PM UTC+3, Mark Hamburg wrote:
>
> Ignoring the commands and subscriptions part, I think this could be 
> summarized as being built around having any of the things that would send a 
> message instead send a new state. This eliminates the level of indirection 
> of wrapping the desire to change the state into a message and then 
> unwrapping the message to actually do the state change.
>

I haven’t though of it in such a well-formalized manner, but yes, that 
sounds like it: I eliminate one level of indirection. Or at least at some 
level, because at the very top there is still a message that triggers the 
update, even if it’s a super-generic one. 樂
 

> It is entirely based on data and hence should be compatible with message 
> recording for the debugger.
>

This looks about right too, as I mentioned in my response to Robin 
, the 
debugger does as good of a job as it can with what I’m giving it. 
 

> On the other hand, the messages will lack semantic information. (One could 
> work around that by adding a logging text field that was set when building 
> the update message but ignored when applying it.)
>

Yeah, that’s true. As I’ve mentioned 
, the 
reason why I haven’t sensed this problem is because I’m not using the Elm 
Reactor, because I don’t know how to get ports playing inside it. 
 

> Where this would seem to fall down is commands and subscriptions. Those 
> are going to produce asynchronous results and would risk baking in a stale 
> model state. This is particularly true for commands. Imagine, for example, 
> wiring up a tick command that will increment a tick field in the model 
> after five seconds. Since the command will be constructed to send the 
> single "set the state" message and since the only model it will have access 
> to is the one that existed when the command was constructed, it basically 
> becomes a "reset the state to where it was five seconds ago" command. If 
> subscriptions really do get rebuilt after every cycle of the update loop, 
> then this isn't a problem for them but the closure construction for each 
> subscription is an expense. If they don't get rebuilt — and the code in the 
> initial posting suggests that instead we're caching a subscriptions value — 
> then as with commands, it would seem easy to end up with code that 
> resurrects stale states.
>

Hm… I haven’t thought about this aspect of the commands+subscriptions duo, 
although I think I understand the mechanics. 樂

So far I think I’m in luck: I have one port (a in/out couple actually) for 
talking to an external rich text editor, which I expect to be modal. The 
user clicks a button, the editor opens in a modal dialog, edit-edit-edit, 
then closes the editor and passes back to Elm, so it’s serialized which 
means there should not be any other changes to the Elm state while the 
editor is open. 

I’m guessing in time, there could come in more things like background 
sync-up of some kind, and then it’ll be really good to keep in mind these 
things that you’re mentioning about stale states. 邏

Thank you! Really good catch! 

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

[elm-discuss] Re: Elm with one message

[Vlad GURDIGA]

Hey Robin! 

Thank you for checking and thinking about my exploration here! 

On Thursday, August 24, 2017 at 11:31:20 AM UTC+3, Robin Heggelund Hansen 
wrote:
>
> Won't this break the reactor/debugger? You can't really tell what sort of 
> messages is being passed around in your application with this model, if you 
> want to export message history, it would fail as well I believe.
>

If by “break” you mean that I won’t be able to tell by looking at the 
message history in the Debugger window, then you’re right: there is only 
one kind of message, and you can’t really tell much just by looking at 
that. 

The reason it wasn’t an issue for me is that I didn’t use the Debugger and 
stopped using the Reactor as soon as I brought in ports. I don’t know how 
to plug in the JS that I call through ports, without having a separate 
index.html 

 
in which I plug the external library 

, the bundle coming out of Elm 
,
 
and then the bits of glue code 

 
to tie them together. 

I’m wondering if anyone has experience with having ports working with the 
Elm Reactor. 樂
 

> I think a better way would be to not have nested components. Keep your 
> entire message hierarchy, and model structure, flat.
>

Yeah, this is the default recommendation that I hear in the Elm community. 
I’ve heard Richard Feldman mentioning that they also have a flat structure 
for their production app at NoRedInk, but I think I just can’t imagine how 
would that look like, and then, as I guess every other mortal, I fallback 
to ways that I know. 

One other reason why I went hierarchical is that I’m used to seeing domain 
models as hierarchies, and in My Ideal World®✨ the code follows the domain 
as close as possible. 

I’m definitely open to hearing, or — even better — *seeing* examples of 
large apps that use a flat structure. 邏

-- 
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] Elm with one message

[Vlad GURDIGA]

Hey Peter! 

Thank you for looking into this thing! 邏

On Thursday, August 24, 2017 at 10:47:24 AM UTC+3, Peter Damoc wrote:
>
> On of the key recommendations of Elm Architecture is to have your messages 
> be just data. 
>
> Your approach is somewhat similar to the approach of elm-sortable-table 
> (except for the Cmds and Subs). 
>
> Without  using Cmds and/or Subs it is an interesting approach if you use 
> it for managing very small bits of state (the open/close status of a 
> dropdown) but I'm afraid that it might bring performance problems if you 
> use it for the entirety of the app. 
>

Regarding “very small bits” — I think this idea was one of the goals of 
going this way: any module represents one domain concept, and its view’s 
callback function deals with a value of that domain concept’s type. If a 
module refers to another domain concept, that concept has its separate 
module with its type, and view, and callback function that only knows about 
itself. (Well, ideally at least, for the most part, you know… )
 

> You basically have to computer all the possible future states of the app.
>

Not sure what you mean here. Could you please expand, or maybe point to an 
example in the code? 樂 

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

[elm-discuss] Elm with one message

[Vlad GURDIGA]

Hey Elm-guys and Elm-gals! 

I have this toy-project 

 
where I’m getting my feet wet with Elm, and I’ve found an approach to 
compose view function that’s a bit different than what The Elm Architecture 
recommends. 邏

Because I found message transformation (mapping 
) 
between nested components to be counterintuitive, I left out messages, for 
the most part. I only have one 

 
for the whole app: 

type Msg
= Update Model (Cmd Msg) (Sub Msg)

update : Msg -> Model -> ( Model, Cmd Msg )update msg model =
case msg of
Update model cmd sub ->
( { model | subscription = sub }, cmd )


Only the top component references it 
,
 
and from then on I use callback-style functions 

 
for wiring up the nested components:

view : Dosar -> (Dosar -> Cmd msg -> Sub msg -> msg) -> Html msgview (Dosar 
data) callback =
let
c data =
callback (Dosar data)
in
div []
[ h1 [] [ text "Dosar nou" ]
, Temei.view data.temei (\v -> c { data | temei = v })
, DocumentExecutoriu.view data.documentExecutoriu (\v -> c { data | 
documentExecutoriu = v } Cmd.none Sub.none)
, Actiune.view data.actiune (\v -> c { data | actiune = v })
]


and also for event handlers 

:

unlabeledTextField : String -> (String -> msg) -> List (Html 
msg)unlabeledTextField defaultValue callback =
[ input
[ value defaultValue
, onInput callback
]
[]
]


It seems to work well so far, and coming from JS I find this style a bit 
more familiar conceptually: I only have functions and values. 邏

I am at about 184K of Elm now, and I’m wondering if anyone else have tried 
to do it this way and maybe found some gotchas that I should be aware of. 
In particular, with regards to how the code compiles to JS and maybe other 
Elm’s inner workings. 樂

Cheers! 鸞

(NOTE: If you want to browse the code, please use this 
revision: https://github.com/gurdiga/xo.elm/tree/9fe9bd1. After that I’m 
bringing in elm-mdl 
, and the code 
will probably get too noisy for the purpose of this conversation. )

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

[elm-discuss] Re: Discovering Elm packages

[Vlad GURDIGA]

It looks like what I was looking for, thank you! 邏

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

[elm-discuss] Re: Discovering Elm packages

[Vlad GURDIGA]

This is nice indeed, but what I’m missing is an RSS feed, so that I don’t 
have to remember the day when I last looked at the list, and begin scanning 
the updates from there.

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

[elm-discuss] Re: Forms with Floats / Dates

[Vlad GURDIGA]

Hi Simon!

As a newcomer to Elm, I too have this issue fresh in my experience, and my 
approach 

 has 
been similar to what Witold Szczerba’s: I’ve built myself a MyDate type to 
hold all the information I need, and a few helper functions that work with 
values of that type:

type alias MyDate =
{ string : String
, date : Maybe Date
, validationMessage : String
}

I think the essence of the approach is to hold user’s input separate from 
the value that we want to make out of it in the end. 邏


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

[elm-discuss] Re: How to manage long running computations in Elm?

[Vlad GURDIGA]

One thing that I think I would have tried in this case, it to delegate the 
long running computation to a webworker 
, and then talk with it through a 
port.

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

[elm-discuss] Is it possible to write a general tree-fold function?

[Vlad GURDIGA]

Hi! 

I’m trying to get through the exercises in the Binary Tree example here: 
http://elm-lang.org/examples/binary-tree.

I’ve got to the 4-th and it seems to me like it’s impossible to solve (with 
the understanding I have now).  樂

So, here it goes:

(4) Write a general fold function that acts on trees. The fold
> function does not need to guarantee a particular order of
> traversal.
>
>fold : (a -> b -> b) -> b -> Tree a -> b


…and here is my attempt to solve it:

fold : (a -> b -> b) -> b -> Tree a -> b
> fold f z tree =
> case tree of
>   Empty -> 

z
>   

  Node v left right ->
> let
>   z_ = f v z
>   l_ = fold f z left
>   r_ = fold f z right
> in
>   {- TODO: figure out how to combine the 3 values of type b -}
>   f v z_


The issue I’m stuck with in the last case —​ Node v left right -> — is that 
I now got 3 values of type b which I can’t fold into the final result: f has 
the type of (a -> b -> b), so if the only value of type a here is z, the 
most I can do is one folding operation, but I get another b as a result. 

My question is: How can I fold the 3 values? Or is this approach workable 
at all? What am I missing? 樂

Cheers! 

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

[elm-discuss] Re: Is Elm weekly still up?

[Vlad GURDIGA]

Nice! Thank you! 8-)

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

[elm-discuss] Re: [ANN] Ellie - the Elm platform in the browser

[Vlad GURDIGA]

This is awesome. 8-)

-- 
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] How to structure the code for a PersonSection widget?

[Vlad GURDIGA]

>
> What types of updates are possible?


For every type of person there is a set of fields, so by updates I mean the 
changes to those fields.

Are the sorts of updates allowed with companies & individuals very similar 
> or very different?


I guess they can be considered similar in that they both have a set of 
fields that the user is expected to fill in or change.

How do we transition from having an Individual to having a Company, and 
> vice versa?


Well, there is the “Type person” dropdown, and whatever the user choses, 
the corresponding set of fields — IndividualFields or CompanyFields — id 
displayed.

I will try the model you’re proposing and see what comes out. 8-)

I see that you’re using the term “Action” instead of “Message” — I like 
that, I feel like action better reflects the concept: it’s something that’s 
happening. 8-)

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

[elm-discuss] How to structure the code for a PersonSection widget?

[Vlad GURDIGA]

Hey guys! 8-)

I’m playing with an app for bailiffs. For the data entry UI I need a 
PersonSection widget to enter the data for a party that participates in a 
case. So a person can be either an individual or a company, so I’m 
imagining this as: a “Person type” dropdown + a set of person-type-specific 
fields.

So, the model looks like this:

type alias Model =
{ personType : PersonType
, personTypeSpecificFieldValues : PersonTypeSpecificValues
}

type PersonType =
= Individual
| Company

type PersonTypeSpecificValues
= IndividualFieldValues IndividualFields.Model
| CompanyFieldValues CompanyFields.Model
 
I have extracted the corresponding pieces of model structure and view into 
IndividualFields.elm and CompanyFields.elm, but I don’t know how to extract 
the model updates. The code here: 
https://github.com/gurdiga/elm-play/blob/master/Main.elm.

I have checked a similar example from the “Elm Beyond The Basics” course 
here: 
https://github.com/knowthen/elm-beyond-basics/blob/master/01The-Elm-Architecture/Main.elm
 
but my case is a bit different: depending on personType I’m trying to 
alternatively store any of the two field value sets (IndividualFieldValues
 or CompanyFieldValues) into a single model member (
personTypeSpecificFieldValues), although I’m not sure this is a good idea.

I’m wondering what’d be an idiomatic approach to build this widget.

Cheers!

-- 
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] What is an idiomatic way to extract a container component?

[Vlad GURDIGA]

That worked! Thank you! 邏

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

[elm-discuss] What is an idiomatic way to extract a container component?

[Vlad GURDIGA]

Hey guys! 邏

I’m trying to build an UI widget that would accept a label and a set of 
fields and render them as a . Here is how it looks implemented as 
a simple Elm function:

labeledContainer : String -> List (Html Message) -> Html 
MessagelabeledContainer labelText fieldList =letlabel =
legend [] [ text labelText ]
infieldset [] (label :: fieldList)


and then I use it like this:

view : Model -> Html Messageview model =labeledContainer "A person section" 
   [ personTypeField initialModel.personType, 
personTypeSpecificFields initialModel.personType]


This is quite common a pattern, so I wanted to extract it as a module so 
that I can reuse it for other widgets. I have tried to just move the 
labeledContainer function in its own file, like this:

module LabeledContainer exposing (..)import Html exposing (..)import 
Html.Attributes exposing (..)labeledContainer : String -> List (Html Message) 
-> Html MessagelabeledContainer labelText fieldList =letlabel = 
   legend [] [ text labelText ]
infieldset [] (label :: fieldList)type Message -- ??? This is 
required as per signature, but I don’t know what should it be= None


and then import it, but the compiler throws this:

elm-make Main.elm --output=index.html
-- TYPE MISMATCH - 
././PersonSection.elm

The type annotation for `view` does not match its definition.

29| view : Model -> Html Message
   ^
The type annotation is saying:

Model -> Html Message

But I am inferring that the definition has this type:

Model -> Html LabeledContainer.Message

-- TYPE MISMATCH - 
././PersonSection.elm

The 2nd argument to function `labeledContainer` is causing a mismatch.

31| labeledContainer "A person section"
32|>[ personTypeField initialModel.personType
33|>, personTypeSpecificFields initialModel.personType
34|>]

Function `labeledContainer` is expecting the 2nd argument to be:

List (Html LabeledContainer.Message)

But it is:

List (Html Message)

Hint: I always figure out the type of arguments from left to right. If an
argument is acceptable when I check it, I assume it is "correct" in 
subsequent
checks. So the problem may actually be in how previous arguments interact 
with
the 2nd.

Detected errors in 1 module.

樂 I’m kind of lost and I’m wondering wether this is The Right Approach® to 
reuse the labeledContainer function, and if not, any link/advice on how can 
I find it would be awesome. 

Cheers! 邏

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