Re: [elm-discuss] Re: Design of Large Elm apps

[Richard Feldman]

>
> I have similar concerns about how deep down the stack Elm can go. At some 
> point, it seems like a good thing to separate business logic concerns from 
> UX logic concerns. 


This can already be done today, using plain old modules and organizing your 
data structures in a way that makes sense. Separating business logic from 
UX logic concerns does not require rearchitecting how your application is 
structured, nor should it. In this case, the way to pay heed to Dijkstra's 
advice is not to *create complexity* out of fear. :)

it could be that business logic belongs in Effects Managers. The 
> documentation around Effects Managers, however, suggests that they should 
> not be created all that often and that would be an odd stance for what 
> would be a standard part of a larger program. The second is to put the 
> business logic layer in as a wrapper around the view layer. That, however, 
> requires a rethink of commands and subscriptions to embrace something more 
> like the more general request concept with them really representing a 
> request for the next layer up to do something or provide some information. 


Nah, these are both solutions in search of a problem. I sometimes wonder 
whether the actual root issue here is that I'm saying "you should just 
build things and then divide later in response to specific pain points" but 
that's a really boring (however correct) answer to what would otherwise be 
a fun problem to try and solve. ;)

I'm not the only one saying this, by the way. Erik Lott is developing a 
large Elm SPA and his recent post 
 echoes 
the same "this is the wrong thing to spend time worrying about" sentiment 
I've been repeating.

tl;dr I hear you, but this concern doesn't materialize in practice. Elm has 
some things yet to work out (DOM APIs, how code splitting should work, 
etc), but architecture is not one of them.

We're all set on that front, so let's go build things! :)

-- 
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: We need a clearer story on architecture

[Richard Feldman]

If you mean dividing a component into 3 separate files - ie. model.elm, 
> update.elm, view.elm , then yeah, that's fine. A single file is too. If you 
> have a massive Elm component that you feel is difficult to manage in a 
> single file, and splitting it into three pieces will make it much easier to 
> maintain and understand, go ahead and do that. Whether your component is 3 
> files, or a single file shouldn't change your overall architecture - it's 
> just a horizontal partitioning of functions.
>

Totally agree! I tried to present this advice on another thread 
 but 
I'm not sure I said it as well as you just did. ;D
 

> I'm not sure what you mean by framework - do you mean elm-parts? If so, 
> just forget about that for now and connect your components manually. It's 
> not a big deal.
>

100% agree.
 

> as the SPA transitions from page to page, we load only the data that is 
> required for that page - We have no central business data in our app, 
> because our server itself serves acts as the single source of truth.
>

+1 to this too

If you're using websockets to update your business model, go ahead and do 
>> that - the model will be automatically reflected in the view. *Your view 
>> shouldn't know anything about websockets.*
>>
>
Strongly agree! Only update should know or care that websockets are 
involved.

I would second the need for better "official" documentation in Elm for 
> folks getting started. There is a learning curve to Elm, but once it 
> "clicks", it'll be more obvious how to piece your application together.
>

I think part of the challenge is figuring out where the gaps are. Threads 
like this are super helpful in surfacing specific questions, so HUGE thanks 
to Oliver for posting it!

-- 
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: Design of Large Elm apps

[Mark Hamburg]

On Aug 17, 2016, at 4:25 AM, Oliver Searle-Barnes  wrote:
> 
> e.g. I'm using websockets to communicate with the server, in my previous 
> experience I would have implemented a Store of some sort which took care of 
> communication with the server and allowed the view layer to just worry about 
> asking for information and sending mutations. 

I have similar concerns about how deep down the stack Elm can go. At some 
point, it seems like a good thing to separate business logic concerns from UX 
logic concerns. Managing complexity is one of the most important parts of doing 
software development. (Or is if you pay heed to Dijkstra.)

These concerns aren't about Elm as a language but have to do with the 
monolithic architecture that Elm encourages. Types make viable larger programs 
than would seem reasonable with JavaScript, but at some there needs to be a way 
to separate concerns.

I can see two potential answers within Elm. (There may be more but these are 
the ones that leap out.) One is that it could be that business logic belongs in 
Effects Managers. The documentation around Effects Managers, however, suggests 
that they should not be created all that often and that would be an odd stance 
for what would be a standard part of a larger program. The second is to put the 
business logic layer in as a wrapper around the view layer. That, however, 
requires a rethink of commands and subscriptions to embrace something more like 
the more general request concept with them really representing a request for 
the next layer up to do something or provide some information.

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.

[elm-discuss] Re: We need a clearer story on architecture

[Erik Lott]

I feel like I just wrote you a vague response - something I try to avoid. 
If you have a specific question about how to build or structure something 
in Elm, don't hesitate to ask.

On Wednesday, August 17, 2016 at 12:19:21 PM UTC-4, Oliver Searle-Barnes 
wrote:
>
> I've been using Elm for about 4 weeks now and having generally been loving 
> it. An area that I'm really having trouble with though is architecture. The 
> basic TEA is a fantastic foundation but the guidelines are really very 
> limited with regards to requirements of a typical SPA. 
>
> * Components - the best advice I've heard is to extract view/model/update 
> separately, as we've seen with elm-mdl this only goes so far though. In the 
> end every large application is going to end up with it's own framework 
> similar to elm-mdl so this seems to be an issue that needs to be resolved 
> somehow. 
> * Separation between view model(component state) and application model 
> (records from the server) - previously I've always had these two separated 
> which has meant that I can have multiple views updating the same server 
> records. 
> * Services - when I've had cross-cutting concerns I would typically manage 
> them in a service tier, e.g. I'm using websockets and want to update the 
> view optimistically. Managing the optimistic vs confirmed state isn't 
> something that I'd expect to have abstracted away from the view.
>
> I'm not really looking to resolve these issues here but I do feel like the 
> community is going in circles. Every day we hear the same questions like 
> "how does parent-child communication work?" but the advice that is given is 
> different depending who you ask (and always feels unresolved). 
>
> A general concern I have is that the impression that's given is that 
> abstraction is treated as something which should be avoided. This seems 
> unworkable for large SPAs. It gives the impression that perhaps no one in 
> the Elm community is really building large applications. 
>
>
> These are my concerns and issues, what I'm really looking for though is an 
> approach to move things forward. Given that there are existing frameworks 
> with well understood architectures I wonder if we should work on guides of 
> the form Elm for React users or Elm for Ember users and try to translate 
> the concepts from those frameworks into practical solutions within Elm. I 
> think this would help clarify the advice and perhaps uncover areas where we 
> need to give some more thought.
>

-- 
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] Code review request

[Thomas Ballinger]

Hi Elm folks! I've enjoyed reading this list for a bit. I've written my 
first Elm thing over the last couple weeks and would love to hear any kind 
of feedback on it. It's an unfinished game jam piece I kept running with so 
the title doesn't make sense.

code: https://github.com/thomasballinger/loveinthetimeoftetris
live: love.ballingt.com (takes about 70 seconds to play all of)

I was going to clean things up the way I know how, but I need to take a 
break to get some other things done and I thought I'd learn more by asking 
how someone else might clean it up. Please don't assume I know what I'm 
doing in the slightest :)

Any feedback would be great, but if prompts are helpful:
* what does this code make it look like I'm missing about Elm?
* what do you think of the extensible record type aliases? I think the way 
I've used them is mostly terrible, I designed them up front instead of 
letting them evolve.
* code style?
* I'm using an elm autoformatter, how's my formatting? Is this style common?
* I don't think I'll be using evancz/elm-graphics in the future since I'll 
be doing less gamey stuff or want to work with canvas more directly. How is 
this usually done?
* I abandoned elm reactor once I started embedding in html, is that a 
viable workflow I should have stuck with for longer?
* I was tempted to start a utils file or look for an external lib but was 
trying to focus on learning the stdlib. Are there pretty common util libs 
folks use? I sure missed some list functions.
* I escaped to JavaScript anytime I thought it would be hard to do 
something with the stdlib, presumably it would be nice to use Elm for some 
of these things?

Thanks so much, and feel free to contact off list if you prefer at 
m...@ballingt.com - if you do I'll report back what I learned to the list.

-- 
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: We need a clearer story on architecture

[Erik Lott]

Oliver, we're currently migrating a large production SPA to Elm - 15+ pages 
non-trivial app, drag and drop interfaces, complex data display, 
integrating with multiple backends, etc. Not a toy.

Components - the best advice I've heard is to extract view/model/update 
> separately, as we've seen with elm-mdl this only goes so far though. In the 
> end every large application is going to end up with it's own framework 
> similar to elm-mdl so this seems to be an issue that needs to be resolved 
> somehow. 


If you mean dividing a component into 3 separate files - ie. model.elm, 
update.elm, view.elm , then yeah, that's fine. A single file is too. If you 
have a massive Elm component that you feel is difficult to manage in a 
single file, and splitting it into three pieces will make it much easier to 
maintain and understand, go ahead and do that. Whether your component is 3 
files, or a single file shouldn't change your overall architecture - it's 
just a horizontal partitioning of functions.

I'm not sure what you mean by framework - do you mean elm-parts? If so, 
just forget about that for now and connect your components manually. It's 
not a big deal.

Separation between view model(component state) and application model 
> (records from the server) - previously I've always had these two separated 
> which has meant that I can have multiple views updating the same server 
> records. 


Yes, exactly right. Conceptually, you'll want to make sure that you have a 
single source of truth for your business state, and your components only 
manage their internal state - they do not store business state in their 
model. Evan has created a great example here: 
https://github.com/evancz/elm-sortable-table/blob/master/README.md#about-api-design
 . 
When you update your business state, any component displaying that state 
should automatically reflect that change. 

Notice that I've said "Conceptually". I get the impression that most folks 
in the Elm discuss board have small apps that can hold their entire 
business model in memory all at once, like a todo application - In that 
case, that business state could be stored all together in the root model 
and used as the single source of truth of business data. In our case, 
however, we have a huge amount of user data, and it would be unreasonable 
to load all of that data into the app at startup. Instead, as the SPA 
transitions from page to page, we load only the data that is required for 
that page - We have no central business data in our app, because our server 
itself serves acts as the single source of truth.

Services - when I've had cross-cutting concerns I would typically manage 
> them in a service tier, e.g. I'm using websockets and want to update the 
> view optimistically. Managing the optimistic vs confirmed state isn't 
> something that I'd expect to have abstracted away from the view.


I'm not sure if I follow you on this, but I think this is something that I 
would actually abstract away from the view. If you're using websockets to 
update your business model, go ahead and do that - the model will be 
automatically reflected in the view. Your view shouldn't know anything 
about websockets.

These are my concerns and issues, what I'm really looking for though is an 
> approach to move things forward. Given that there are existing frameworks 
> with well understood architectures I wonder if we should work on guides of 
> the form Elm for React users or Elm for Ember users and try to translate 
> the concepts from those frameworks into practical solutions within Elm. I 
> think this would help clarify the advice and perhaps uncover areas where we 
> need to give some more thought.


I would second the need for better "official" documentation in Elm for 
folks getting started. There is a learning curve to Elm, but once it 
"clicks", it'll be more obvious how to piece your application together.





On Wednesday, August 17, 2016 at 12:19:21 PM UTC-4, Oliver Searle-Barnes 
wrote:
>
> I've been using Elm for about 4 weeks now and having generally been loving 
> it. An area that I'm really having trouble with though is architecture. The 
> basic TEA is a fantastic foundation but the guidelines are really very 
> limited with regards to requirements of a typical SPA. 
>
> * Components - the best advice I've heard is to extract view/model/update 
> separately, as we've seen with elm-mdl this only goes so far though. In the 
> end every large application is going to end up with it's own framework 
> similar to elm-mdl so this seems to be an issue that needs to be resolved 
> somehow. 
> * Separation between view model(component state) and application model 
> (records from the server) - previously I've always had these two separated 
> which has meant that I can have multiple views updating the same server 
> records. 
> * Services - when I've had cross-cutting concerns I would typically manage 
> them in a service tier, e.g. I'm using websockets and want to 

Re: [elm-discuss] Publishing native modules

[Nick H]

Since port modules are not publishable, what do you do if you want to
publish an Elm API that needs a port? I would refer to elm-css
. It seems
the recommended practice is simply documenting how the user should set up
their port module.

On Wed, Aug 17, 2016 at 2:23 PM, Nick H  wrote:

> Packages with native modules are not publishable.
>
> Native modules are a deprecated approach to JS interop, used only by the
> core libraries and a few community packages that were lucky enough to get
> approved before the native review process was discontinued. Nowadays, all
> JS interop is supposed to be done using ports & port modules.
>
> Packages with port modules are also not publishable.
>
> The best explanation that I have seen for why things are this way has been
> in Richard's very thoughtful comments in this thread
> .
>
>
> On Wed, Aug 17, 2016 at 1:28 PM, Conrad Parker 
> wrote:
>
>> Hi,
>>
>> I'd like to publish a couple of packages which would use native
>> modules. What is the procedure currently?
>>
>> The packages I'd like to publish are:
>>
>>   1) gamepad support
>>
>> This was zimbatm/elm-gamepad, I've updated it for elm-0.17 as part of
>> kfish/dreambuggy. Ideally we'd make an elm-community/gamepad package.
>>
>>   2) support for dynamic types
>>
>> The dynamic types package is trivial and ready to publish, from
>> https://github.com/kfish/dynamic
>>
>> I'm using this interface eg. in the dynamic dispatch, managing
>> arbitrary objects in
>> https://github.com/kfish/dreambuggy/blob/master/src/Thing.elm
>> Obviously, use of dynamic types should be discouraged in general. I
>> use them here to separate the concerns of 3D objects (Things), which
>> have their own TEA model/view/update architecture, from the world
>> engine's own TEA.
>>
>> cheers,
>>
>> Conrad.
>>
>> --
>> 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] Publishing native modules

[Nick H]

Packages with native modules are not publishable.

Native modules are a deprecated approach to JS interop, used only by the
core libraries and a few community packages that were lucky enough to get
approved before the native review process was discontinued. Nowadays, all
JS interop is supposed to be done using ports & port modules.

Packages with port modules are also not publishable.

The best explanation that I have seen for why things are this way has been
in Richard's very thoughtful comments in this thread
.


On Wed, Aug 17, 2016 at 1:28 PM, Conrad Parker  wrote:

> Hi,
>
> I'd like to publish a couple of packages which would use native
> modules. What is the procedure currently?
>
> The packages I'd like to publish are:
>
>   1) gamepad support
>
> This was zimbatm/elm-gamepad, I've updated it for elm-0.17 as part of
> kfish/dreambuggy. Ideally we'd make an elm-community/gamepad package.
>
>   2) support for dynamic types
>
> The dynamic types package is trivial and ready to publish, from
> https://github.com/kfish/dynamic
>
> I'm using this interface eg. in the dynamic dispatch, managing
> arbitrary objects in
> https://github.com/kfish/dreambuggy/blob/master/src/Thing.elm
> Obviously, use of dynamic types should be discouraged in general. I
> use them here to separate the concerns of 3D objects (Things), which
> have their own TEA model/view/update architecture, from the world
> engine's own TEA.
>
> cheers,
>
> Conrad.
>
> --
> 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.

[elm-discuss] Publishing native modules

[Conrad Parker]

Hi,

I'd like to publish a couple of packages which would use native
modules. What is the procedure currently?

The packages I'd like to publish are:

  1) gamepad support

This was zimbatm/elm-gamepad, I've updated it for elm-0.17 as part of
kfish/dreambuggy. Ideally we'd make an elm-community/gamepad package.

  2) support for dynamic types

The dynamic types package is trivial and ready to publish, from
https://github.com/kfish/dynamic

I'm using this interface eg. in the dynamic dispatch, managing
arbitrary objects in
https://github.com/kfish/dreambuggy/blob/master/src/Thing.elm
Obviously, use of dynamic types should be discouraged in general. I
use them here to separate the concerns of 3D objects (Things), which
have their own TEA model/view/update architecture, from the world
engine's own TEA.

cheers,

Conrad.

-- 
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: More thorough side-effect isolation

[OvermindDL1]

On Wednesday, August 17, 2016 at 2:00:47 PM UTC-6, Kasey Speakman wrote:
>
> One question @Evan. How are you keeping events? I would assume in Elm 
> structures, since you can't send union types through ports be default. 
> Asking in case you have some magic for transferring them out to Javascript. 
> The idea of writing de/en-coders for every message case (in order to 
> transmit or load/save in Session State) makes my brain shut down.
>

This looks like the code from a cursor search, in other words it is stored 
in elm it seem?

https://github.com/elm-lang/elm-reactor/blob/master/src/debugger/History.elm 

-- 
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: More thorough side-effect isolation

[OvermindDL1]

On Wednesday, August 17, 2016 at 1:15:49 PM UTC-6, Evan wrote:
>
> Warning, I have not read everything here. About ignoring commands though, 
> think of the type of a Html.App.program
>
> program : { init, update, view, subscriptions } -> Program Never
>
> The essence of this is just a record. So you can wrap that record however 
> you want. Say like this:
>
> myProgram : ({ init, update, view, subscriptions } as details) =
>   { details | update = \msg model -> (fst (update msg model), Cmd.none) }
>
> Now you have programs that drop all commands.
>
> I'm in the process of revining elm-reactor to track history for exactly 
> the kinds of things you have in mind (testing, etc.) and I am using this 
> basic technique. Anyone can do this. You can write time-travel in pure Elm 
> this way. Make the update log all the messages it gets.
>

This is what I do in my ProgramEx library to have the separate filtering 
step, and is how I would imagine a thing like this thread would be done as 
well, the API itself though still seems hard to get right.  Hmm, an idea 
though...

What if update was all just Cmd's, it did not return a model, but certain 
commands would update the model.  like using the `put` and `update` syntax 
that I propose in the other thread, you could do something like:
```elm

# Example for a multi-counter where each has an Integer IDupdate : Msg -> Model 
-> Cmd Msgupdate msg model =
  case msg of

{- Example using Cmd.putModel -}
Increment id ->
  Cmd.putModel
[Model.Fields.counter, Model.Counter.Key id]
( Just ( (Dict.get id model.counters |> Maybe.withDefault 0) + 1 ) )

{- Example using Cmd.updateModel -}
Decrement id ->
  Cmd.updateModel
[Model.Fields.counter, Model.Counter.Key id]
(\t ->
  Just ((t |> Maybe.withDefault 1 ) - 1)
)

```

That way both commands are commands, and model mutations are commands.  A 
benefit is since you know which are prev->next state updates (updateModel) 
and which are purely 'set' updates (putModel) then you know how they could 
be combined and simplify their storage accordingly.  You could even not 
have a `Cmd.updateModel` and instead require another command with a new 
argument that then sets it via a Put, thus no functions would be stored at 
the expense of another model-update message for updates (which is probably 
better anyway for such tracking).  As such the above Decrement would end up 
being something like this for this specific case:
```elm

Decrement id ->
  Cmd.msg (Increment -1)

```

-- 
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: More thorough side-effect isolation

[Kasey Speakman]

One question @Evan. How are you keeping events? I would assume in Elm 
structures, since you can't send union types through ports be default. 
Asking in case you have some magic for transferring them out to Javascript. 
The idea of writing de/en-coders for every message case (in order to 
transmit or load/save in Session State) makes my brain shut down.

On Wednesday, August 17, 2016 at 2:15:49 PM UTC-5, Evan wrote:
>
> Warning, I have not read everything here. About ignoring commands though, 
> think of the type of a Html.App.program
>
> program : { init, update, view, subscriptions } -> Program Never
>
> The essence of this is just a record. So you can wrap that record however 
> you want. Say like this:
>
> myProgram : ({ init, update, view, subscriptions } as details) =
>   { details | update = \msg model -> (fst (update msg model), Cmd.none) }
>
> Now you have programs that drop all commands.
>
> I'm in the process of revining elm-reactor to track history for exactly 
> the kinds of things you have in mind (testing, etc.) and I am using this 
> basic technique. Anyone can do this. You can write time-travel in pure Elm 
> this way. Make the update log all the messages it gets.
>
> Again, I have no idea what's happening in this discussion though, so 
> hopefully that's a helpful insight.
>
>
> On Thursday, August 11, 2016 at 10:37:48 AM UTC-7, Kasey Speakman wrote:
>>
>> Hi all,
>>
>> I'm getting to know Elm. I recently read this article 
>>  about 
>> event sourcing in Elm. Essentially, the time-traveling debugger is event 
>> sourcing. But it's a pattern that could be used in an app for other great 
>> things. (Lots of literature on that in the internet. One particular 
>> interest of mine is producing a complete failing use case from live running 
>> app -- it's just all the events. Obviously wouldn't work for real-time 
>> apps... too many events... but for most of mine it would.)
>>
>> However, one thing that is a hindrance (to the TTD as well) and that has 
>> always bothered me about the Elm examples is this signature.
>>
>> update : Msg -> Model -> (Model, Cmd Msg)
>>
>>
>> Because an update returns both a Model and Cmd, for instance, the 
>> time-traveling debugger "...needs to tell the runtime not to perform any 
>> side-effects during replay to avoid these issues"[1]. An event-sourcing 
>> implementation would have to figure a way to do the same without runtime 
>> hooks.
>>
>> This part of the architecture mixes concerns by returning a model and 
>> effects. And usually (not always) you see each message returning one or the 
>> other, not both. From the docs:
>>
>> update : Msg -> Model -> (Model, Cmd Msg)
>> update msg model =
>>   case msg of
>> Roll ->
>>   (model, Random.generate NewFace (Random.int 1 6))
>>
>> NewFace newFace ->
>>   (Model newFace, Cmd.none)
>>
>>
>> Here, Roll does an effect, but nothing with the model. NewFace returns a 
>> new model but no effects. You do have cases where you want to update a UI 
>> element when an outside effect happens, like activating a spinner when 
>> sending off an HTTP request. Those could still be modeled as two "Cmd"s. 
>> One that immediately returns a separate message affecting the model's 
>> spinner. And another to do the HTTP request.
>>
>> So it seems to me that there are really two concepts at work here. There 
>> are "events" which have happened and can be used completely 
>> deterministically, and there are commands which interface with the outside 
>> and may produce events.
>>
>> I think it's something worth pointing out and considering for the future. 
>> What do y'all think?
>>
>> Kasey
>>
>> [1] source , section "How Elm makes this 
>> possible", subsection "Purity", last paragraph
>>
>

-- 
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: More thorough side-effect isolation

[Kasey Speakman]

So, reading through your implementation:

Bug: In `projection`, you're doing a foldl on your history, but you're 
putting new events at the head of your history using cons (::). So your 
history be replayed in reverse order. I think there was a quite humorous 
Red Dwarf episode about that.

Possible typo: `process` should return a Cmd Command instead of Cmd Event 
if we're talking about the Process Manager pattern. I would also do a List 
instead of Maybe. (You can Cmd.batch them, and Cmd.none is actually 
implemented as Cmd.batch on an empty list)

Also, `process` is called incorrectly if it only uses Events to make 
decisions. It should be called with all history, not just the events 
generated from the one command. With only current events, it might be 
missing the information needed to know if a Command is warranted. RPG 
example: your game didn't have full history, so even though you got a 
GoblinSlayer sword 5 minutes ago, it didn't on turn Glow on when 
GoblinsEnteredTheArea.

`commandHandler` - I believe the definition of commandHandler as `Command 
-> Events -> Events` is too narrow. A command handler is often responsible 
for wrangling external resources (e.g. API calls). The only way to make 
this possible is to return `Cmd Events`. I also imagine it possible to 
perform some IO through Cmd and subsequently need to issue another Command 
to do something else with logic or IO. (Generally, I think multiple API 
calls would be handled better by an API gateway, but I wouldn't want to 
limit possibilities here.) I think Cmd Msg or Cmd (List Msg) would be more 
expected here.

As previously mentioned, I don't think it's a good idea to carry around the 
increment value and actually calculate it in the `eventHandler`. The 
relating of Incremented to the plus operator and Decremented to minus is 
logic, and logic should be under the command handler. Updating a model with 
event data should be as dumb as possible, because it should not have the 
possibility to fail when simply responding to facts. Not sure if plus/minus 
overflow in Elm (in JS, they flip sign on overflow), but other kinds of 
operators could.

On Wednesday, August 17, 2016 at 11:32:27 AM UTC-5, Marco Perone wrote:
>
> Hi!
>
> I was eventually able to read carefully the thread and give some thoughts 
> about it.
>
> @kasey, I had a look to your Gist and it looks really interesting! Some 
> notes about it:
>
> - I think it would be better to store in the parameter of the Fact's the 
> increment, and not the state of the application. It looks to me that you 
> are mixing two concerns, i.e. the state of the applications and the events 
> that happens to it
>
> - if I'm not mistaken, from you implementation it seems that only Act's 
> (and not Fact's) can generate new Cmd's. I think that is some applications 
> there could be the need to react automatically with a new Cmd to some 
> events that happened
>
> To make everything clearer in my mind, I wrote my own implementation of 
> something similar to what you did. You can find it here:
>
> https://github.com/marcosh/elm-escqrs/blob/master/EsCqrsMain.elm
>
> It should be just a functional transposition of a standard es/cqrs 
> architecture (I actually used also es/cqrs jargon), adacted to the Elm 
> Architecture.
>
> I'd really like to know what you think of it. Let me know if something is 
> not clear enough
>
> On Sunday, August 14, 2016 at 7:37:25 AM UTC+2, Kasey Speakman wrote:
>>
>> So, I made a Gist 
>>  of 
>> the helper stuff which splits Facts and Acts. I call the helper Factor... 
>> (Fact or Act ~=> Factor). There is a subsequent comment with an example 
>> program explaining the helper's usage.
>>
>>

-- 
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: More thorough side-effect isolation

[Kasey Speakman]

Dunno why I didn't think of that. It should have been obvious to me.

On Wednesday, August 17, 2016 at 2:15:49 PM UTC-5, Evan wrote:
>
> Warning, I have not read everything here. About ignoring commands though, 
> think of the type of a Html.App.program
>
> program : { init, update, view, subscriptions } -> Program Never
>
> The essence of this is just a record. So you can wrap that record however 
> you want. Say like this:
>
> myProgram : ({ init, update, view, subscriptions } as details) =
>   { details | update = \msg model -> (fst (update msg model), Cmd.none) }
>
> Now you have programs that drop all commands.
>
> I'm in the process of revining elm-reactor to track history for exactly 
> the kinds of things you have in mind (testing, etc.) and I am using this 
> basic technique. Anyone can do this. You can write time-travel in pure Elm 
> this way. Make the update log all the messages it gets.
>
> Again, I have no idea what's happening in this discussion though, so 
> hopefully that's a helpful insight.
>
>
> On Thursday, August 11, 2016 at 10:37:48 AM UTC-7, Kasey Speakman wrote:
>>
>> Hi all,
>>
>> I'm getting to know Elm. I recently read this article 
>>  about 
>> event sourcing in Elm. Essentially, the time-traveling debugger is event 
>> sourcing. But it's a pattern that could be used in an app for other great 
>> things. (Lots of literature on that in the internet. One particular 
>> interest of mine is producing a complete failing use case from live running 
>> app -- it's just all the events. Obviously wouldn't work for real-time 
>> apps... too many events... but for most of mine it would.)
>>
>> However, one thing that is a hindrance (to the TTD as well) and that has 
>> always bothered me about the Elm examples is this signature.
>>
>> update : Msg -> Model -> (Model, Cmd Msg)
>>
>>
>> Because an update returns both a Model and Cmd, for instance, the 
>> time-traveling debugger "...needs to tell the runtime not to perform any 
>> side-effects during replay to avoid these issues"[1]. An event-sourcing 
>> implementation would have to figure a way to do the same without runtime 
>> hooks.
>>
>> This part of the architecture mixes concerns by returning a model and 
>> effects. And usually (not always) you see each message returning one or the 
>> other, not both. From the docs:
>>
>> update : Msg -> Model -> (Model, Cmd Msg)
>> update msg model =
>>   case msg of
>> Roll ->
>>   (model, Random.generate NewFace (Random.int 1 6))
>>
>> NewFace newFace ->
>>   (Model newFace, Cmd.none)
>>
>>
>> Here, Roll does an effect, but nothing with the model. NewFace returns a 
>> new model but no effects. You do have cases where you want to update a UI 
>> element when an outside effect happens, like activating a spinner when 
>> sending off an HTTP request. Those could still be modeled as two "Cmd"s. 
>> One that immediately returns a separate message affecting the model's 
>> spinner. And another to do the HTTP request.
>>
>> So it seems to me that there are really two concepts at work here. There 
>> are "events" which have happened and can be used completely 
>> deterministically, and there are commands which interface with the outside 
>> and may produce events.
>>
>> I think it's something worth pointing out and considering for the future. 
>> What do y'all think?
>>
>> Kasey
>>
>> [1] source , section "How Elm makes this 
>> possible", subsection "Purity", last paragraph
>>
>

-- 
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: text editor for Elm + GLSL

[Nick H]

Ahh, multi-mode! That is something to remember for the next time the moon
turns full and I hunger for Elisp.  :-)

I tried putting the GLSL code in a string constant, and the results are
different, but not better. With a GLSL block, elm-format ignores the code,
and elm-mode indents erratically. With a string block, elm-format still
ignores the code, and elm-mode strips out all indentation.

Basically, elm-format doesn't try to help, and elm-mode tries to help but
gets in the way. Is there an editor that can do better?

On Wed, Aug 17, 2016 at 2:27 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Tuesday, August 16, 2016 at 6:54:38 PM UTC+1, Nick H wrote:
>>
>> The list has been talking about text editors lately. For those of you who
>> use elm-webgl, is there a text editor that can properly format GLSL code
>> blocks?
>>
>> fragmentShader : Shader {} Uniform Varying
>>> fragmentShader =
>>> [glsl|
>>>  precision mediump float;
>>>  varying vec4 fragColor;
>>>
>>>  void main () {
>>>  gl_FragColor = fragColor;
>>>  }
>>> |]
>>>
>>
>> I am an Emacs user. As has been mentioned before, Emacs elm-mode
>> indentation is busted. This isn't a problem for me most of the time, thanks
>> to elm-format. But elm-format does not touch GLSL blocks, so I'm stuck
>> fixing the indentation by hand.
>>
>> Any suggestions? Thanks!
>>
>
> Emacs multi-mode ? :-) sorry couldn't resist...
>
> Does elm-format leave strings alone? In which case you could put the glsl
> code in a string constant?
>
> --
> 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.

[elm-discuss] Re: More thorough side-effect isolation

[Evan]

Warning, I have not read everything here. About ignoring commands though, 
think of the type of a Html.App.program

program : { init, update, view, subscriptions } -> Program Never

The essence of this is just a record. So you can wrap that record however 
you want. Say like this:

myProgram : ({ init, update, view, subscriptions } as details) =
  { details | update = \msg model -> (fst (update msg model), Cmd.none) }

Now you have programs that drop all commands.

I'm in the process of revining elm-reactor to track history for exactly the 
kinds of things you have in mind (testing, etc.) and I am using this basic 
technique. Anyone can do this. You can write time-travel in pure Elm this 
way. Make the update log all the messages it gets.

Again, I have no idea what's happening in this discussion though, so 
hopefully that's a helpful insight.


On Thursday, August 11, 2016 at 10:37:48 AM UTC-7, Kasey Speakman wrote:
>
> Hi all,
>
> I'm getting to know Elm. I recently read this article 
>  about 
> event sourcing in Elm. Essentially, the time-traveling debugger is event 
> sourcing. But it's a pattern that could be used in an app for other great 
> things. (Lots of literature on that in the internet. One particular 
> interest of mine is producing a complete failing use case from live running 
> app -- it's just all the events. Obviously wouldn't work for real-time 
> apps... too many events... but for most of mine it would.)
>
> However, one thing that is a hindrance (to the TTD as well) and that has 
> always bothered me about the Elm examples is this signature.
>
> update : Msg -> Model -> (Model, Cmd Msg)
>
>
> Because an update returns both a Model and Cmd, for instance, the 
> time-traveling debugger "...needs to tell the runtime not to perform any 
> side-effects during replay to avoid these issues"[1]. An event-sourcing 
> implementation would have to figure a way to do the same without runtime 
> hooks.
>
> This part of the architecture mixes concerns by returning a model and 
> effects. And usually (not always) you see each message returning one or the 
> other, not both. From the docs:
>
> update : Msg -> Model -> (Model, Cmd Msg)
> update msg model =
>   case msg of
> Roll ->
>   (model, Random.generate NewFace (Random.int 1 6))
>
> NewFace newFace ->
>   (Model newFace, Cmd.none)
>
>
> Here, Roll does an effect, but nothing with the model. NewFace returns a 
> new model but no effects. You do have cases where you want to update a UI 
> element when an outside effect happens, like activating a spinner when 
> sending off an HTTP request. Those could still be modeled as two "Cmd"s. 
> One that immediately returns a separate message affecting the model's 
> spinner. And another to do the HTTP request.
>
> So it seems to me that there are really two concepts at work here. There 
> are "events" which have happened and can be used completely 
> deterministically, and there are commands which interface with the outside 
> and may produce events.
>
> I think it's something worth pointing out and considering for the future. 
> What do y'all think?
>
> Kasey
>
> [1] source , section "How Elm makes this 
> possible", subsection "Purity", last paragraph
>

-- 
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: More thorough side-effect isolation

[Marco Perone]

@OvermindDL1, you're right, model.write is goin to get pretty huge. I
actually didn't try how far you could get with this approach until it
becomes a burden and starts to slow down the whole application. It'd be
really interesting to build a simple chat app with this approach and see
how big the model becomes.

A thing that come to mind that could help is use some data store (local
storage, for example) to persist the main part of the history and keep only
the latest events in memory

2016-08-17 18:49 GMT+02:00 OvermindDL1 :

> Hmm, interesting style, although I worry about how huge the model.write
> could get considering it saves every event ever. Say in a given chat app
> this could get amazingly huge.  How would that be handled in this pattern?
>
>
> On Wednesday, August 17, 2016 at 10:32:27 AM UTC-6, Marco Perone wrote:
>>
>> Hi!
>>
>> I was eventually able to read carefully the thread and give some thoughts
>> about it.
>>
>> @kasey, I had a look to your Gist and it looks really interesting! Some
>> notes about it:
>>
>> - I think it would be better to store in the parameter of the Fact's the
>> increment, and not the state of the application. It looks to me that you
>> are mixing two concerns, i.e. the state of the applications and the events
>> that happens to it
>>
>> - if I'm not mistaken, from you implementation it seems that only Act's
>> (and not Fact's) can generate new Cmd's. I think that is some applications
>> there could be the need to react automatically with a new Cmd to some
>> events that happened
>>
>> To make everything clearer in my mind, I wrote my own implementation of
>> something similar to what you did. You can find it here:
>>
>> https://github.com/marcosh/elm-escqrs/blob/master/EsCqrsMain.elm
>>
>> It should be just a functional transposition of a standard es/cqrs
>> architecture (I actually used also es/cqrs jargon), adacted to the Elm
>> Architecture.
>>
>> I'd really like to know what you think of it. Let me know if something is
>> not clear enough
>>
>> On Sunday, August 14, 2016 at 7:37:25 AM UTC+2, Kasey Speakman wrote:
>>>
>>> So, I made a Gist
>>>  of
>>> the helper stuff which splits Facts and Acts. I call the helper Factor...
>>> (Fact or Act ~=> Factor). There is a subsequent comment with an example
>>> program explaining the helper's usage.
>>>
>>> --
> 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/yKRYkoiQmPs/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.

[elm-discuss] Re: More thorough side-effect isolation

[Kasey Speakman]

Btw, the "event compression" only works for sequential messages of 
identical type (assuming idempotence). So Incremented 1, Incremented 2 
could compress to just Incremented 2, but Incremented 1, Decremented 0 
could not compress obviously. The counter example is bad here as it doesn't 
express how different the events can affect the model in orthogonal ways... 
all these events are affecting the same piece of data, so they could all be 
compressed down to the last event. But that's not a guarantee you can make 
in general.

On Wednesday, August 17, 2016 at 1:22:20 PM UTC-5, Kasey Speakman wrote:
>
> Thanks for the comment!
>
> - I think it would be better to store in the parameter of the Fact's the 
>> increment, and not the state of the application. It looks to me that you 
>> are mixing two concerns, i.e. the state of the applications and the events 
>> that happens to it
>>
>
> The counter example is too simple to properly express this, but the Fact 
> doesn't store the whole application state, only data applicable to the 
> event. For instance, imagine the apply function was `NameChanged name -> 
> {model | Name = name }`. It doesn't change the whole model, but it changes 
> a part of the model it applies to. In the counter example, the part 
> unfortunately happens to be the whole model.
>
> If the data instead carried the increment instead of the final value, then 
> the logic of how the counter works is decentralized... part of it (model + 
> 1, model - 1) is in the apply function now. You wouldn't put other kinds of 
> logic in the apply function (e.g. HTTP call). Storing the increment in the 
> event is also no longer idempotent. Idempotence is typically something you 
> want on the back-end because it allows you to deliver a message more than 
> once with no ill effects. However, it is valuable in the UI because it 
> could allow you to "compress" events to prevent history from getting too 
> large. For example, say someone spammed the Increment button 100 times, 
> giving you Incremented 1... Incremented 100. When applied in order, the 
> result is the same as just applying the last event of the same type; 
> Incremented 100. Now you are loosing history that way (and undo-ability), 
> but you can choose to make that trade-off for space without a deep 
> understanding of the events. In order to do the same if you were carrying 
> the increment, you would have understand what the event was doing and apply 
> logic to the messages to figure out the "compressed" message's data (add 
> the increments), so you have another place where you are putting logic.
>
> However, the compression benefit is probably mitigated by Elm not having a 
> way to determine if two union cases are the same type (no metaprogramming 
> that I know of). You'd have to manually check for specific sequential 
> messages you want to compress.
>
> - if I'm not mistaken, from you implementation it seems that only Act's 
>> (and not Fact's) can generate new Cmd's. I think that is some applications 
>> there could be the need to react automatically with a new Cmd to some 
>> events that happened
>>
>
> This (events to commands, aka Process Manager aka Saga) is not covered in 
> my example. Seems like the easiest way to accomplish this is to have 3rd 
> method which is called after `apply` that checks the model (or the part 
> where the process manager has been keeping track of state) to see if a new 
> Act needs to be issued. Maybe something like this:
>
> propose : Model -> Cmd Act
> propose model =
>   if model.orderProcess.orderPlaced && model.orderProcess.paymentFailed 
> then
> CancelOrder model.orderProcess.orderId |> actCmd
>   else if model.orderProcess.orderPlaced && model.orderProcess.paidInFull 
> then
> ShipOrder model.orderProcess.orderId |> actCmd
>   else
> Cmd.none
>
> That's assuming your `apply` method is updating the model with those flags 
> in response to the appropriate events. Of course, this particular logic 
> doesn't make sense on the front end, but this type of pattern could.
>
> On Wednesday, August 17, 2016 at 11:32:27 AM UTC-5, Marco Perone wrote:
>>
>> Hi!
>>
>> I was eventually able to read carefully the thread and give some thoughts 
>> about it.
>>
>> @kasey, I had a look to your Gist and it looks really interesting! Some 
>> notes about it:
>>
>> - I think it would be better to store in the parameter of the Fact's the 
>> increment, and not the state of the application. It looks to me that you 
>> are mixing two concerns, i.e. the state of the applications and the events 
>> that happens to it
>>
>> - if I'm not mistaken, from you implementation it seems that only Act's 
>> (and not Fact's) can generate new Cmd's. I think that is some applications 
>> there could be the need to react automatically with a new Cmd to some 
>> events that happened
>>
>> To make everything clearer in my mind, I wrote my own implementation of 
>> something similar to what you did. You can find it here:
>>

[elm-discuss] Re: More thorough side-effect isolation

[Kasey Speakman]

Thanks for the comment!

- I think it would be better to store in the parameter of the Fact's the 
> increment, and not the state of the application. It looks to me that you 
> are mixing two concerns, i.e. the state of the applications and the events 
> that happens to it
>

The counter example is too simple to properly express this, but the Fact 
doesn't store the whole application state, only data applicable to the 
event. For instance, imagine the apply function was `NameChanged name -> 
{model | Name = name }`. It doesn't change the whole model, but it changes 
a part of the model it applies to. In the counter example, the part 
unfortunately happens to be the whole model.

If the data instead carried the increment instead of the final value, then 
the logic of how the counter works is decentralized... part of it (model + 
1, model - 1) is in the apply function now. You wouldn't put other kinds of 
logic in the apply function (e.g. HTTP call). Storing the increment in the 
event is also no longer idempotent. Idempotence is typically something you 
want on the back-end because it allows you to deliver a message more than 
once with no ill effects. However, it is valuable in the UI because it 
could allow you to "compress" events to prevent history from getting too 
large. For example, say someone spammed the Increment button 100 times, 
giving you Incremented 1... Incremented 100. When applied in order, the 
result is the same as just applying the last event of the same type; 
Incremented 100. Now you are loosing history that way (and undo-ability), 
but you can choose to make that trade-off for space without a deep 
understanding of the events. In order to do the same if you were carrying 
the increment, you would have understand what the event was doing and apply 
logic to the messages to figure out the "compressed" message's data (add 
the increments), so you have another place where you are putting logic.

However, the compression benefit is probably mitigated by Elm not having a 
way to determine if two union cases are the same type (no metaprogramming 
that I know of). You'd have to manually check for specific sequential 
messages you want to compress.

- if I'm not mistaken, from you implementation it seems that only Act's 
> (and not Fact's) can generate new Cmd's. I think that is some applications 
> there could be the need to react automatically with a new Cmd to some 
> events that happened
>

This (events to commands, aka Process Manager aka Saga) is not covered in 
my example. Seems like the easiest way to accomplish this is to have 3rd 
method which is called after `apply` that checks the model (or the part 
where the process manager has been keeping track of state) to see if a new 
Act needs to be issued. Maybe something like this:

propose : Model -> Cmd Act
propose model =
  if model.orderProcess.orderPlaced && model.orderProcess.paymentFailed then
CancelOrder model.orderProcess.orderId |> actCmd
  else if model.orderProcess.orderPlaced && model.orderProcess.paidInFull 
then
ShipOrder model.orderProcess.orderId |> actCmd
  else
Cmd.none

That's assuming your `apply` method is updating the model with those flags 
in response to the appropriate events. Of course, this particular logic 
doesn't make sense on the front end, but this type of pattern could.

On Wednesday, August 17, 2016 at 11:32:27 AM UTC-5, Marco Perone wrote:
>
> Hi!
>
> I was eventually able to read carefully the thread and give some thoughts 
> about it.
>
> @kasey, I had a look to your Gist and it looks really interesting! Some 
> notes about it:
>
> - I think it would be better to store in the parameter of the Fact's the 
> increment, and not the state of the application. It looks to me that you 
> are mixing two concerns, i.e. the state of the applications and the events 
> that happens to it
>
> - if I'm not mistaken, from you implementation it seems that only Act's 
> (and not Fact's) can generate new Cmd's. I think that is some applications 
> there could be the need to react automatically with a new Cmd to some 
> events that happened
>
> To make everything clearer in my mind, I wrote my own implementation of 
> something similar to what you did. You can find it here:
>
> https://github.com/marcosh/elm-escqrs/blob/master/EsCqrsMain.elm
>
> It should be just a functional transposition of a standard es/cqrs 
> architecture (I actually used also es/cqrs jargon), adacted to the Elm 
> Architecture.
>
> I'd really like to know what you think of it. Let me know if something is 
> not clear enough
>
> On Sunday, August 14, 2016 at 7:37:25 AM UTC+2, Kasey Speakman wrote:
>>
>> So, I made a Gist 
>>  of 
>> the helper stuff which splits Facts and Acts. I call the helper Factor... 
>> (Fact or Act ~=> Factor). There is a subsequent comment with an example 
>> program explaining the helper's usage.
>>
>>

-- 
You received this message because 

Re: [elm-discuss] Human readable

[Ambrose Laing]

At https://groups.google.com/forum/#!msg/elm-discuss/h9VbI4QrJQQ/Z26BaomUAwAJ

On Wednesday, August 17, 2016 at 1:26:46 PM UTC-4, Ambrose Laing wrote:
>
> To everyone who wanted to have the elm-compiler produce line numbers and 
> column numbers that can help a traditional editor (like emacs for example) 
> to navigate to error locations:  I discussed this a bit with Evan, and he 
> suggested working with the json output, so then I came up with this 
> solution for now:
>
> Please see: http://github.com/aklaing/call-elm-make
>
> Let me know if you find this helpful, especially you're not an emacs user 
> :-)
>
> Thanks,
>
> Ambrose
>
>>
>>

-- 
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] Human readable

[Ambrose Laing]

To everyone who wanted to have the elm-compiler produce line numbers and 
column numbers that can help a traditional editor (like emacs for example) 
to navigate to error locations:  I discussed this a bit with Evan, and he 
suggested working with the json output, so then I came up with this 
solution for now:

Please see: http://github.com/aklaing/call-elm-make

Let me know if you find this helpful, especially you're not an emacs user 
:-)

Thanks,

Ambrose

>
>

-- 
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: More thorough side-effect isolation

[OvermindDL1]

Hmm, interesting style, although I worry about how huge the model.write 
could get considering it saves every event ever. Say in a given chat app 
this could get amazingly huge.  How would that be handled in this pattern?


On Wednesday, August 17, 2016 at 10:32:27 AM UTC-6, Marco Perone wrote:
>
> Hi!
>
> I was eventually able to read carefully the thread and give some thoughts 
> about it.
>
> @kasey, I had a look to your Gist and it looks really interesting! Some 
> notes about it:
>
> - I think it would be better to store in the parameter of the Fact's the 
> increment, and not the state of the application. It looks to me that you 
> are mixing two concerns, i.e. the state of the applications and the events 
> that happens to it
>
> - if I'm not mistaken, from you implementation it seems that only Act's 
> (and not Fact's) can generate new Cmd's. I think that is some applications 
> there could be the need to react automatically with a new Cmd to some 
> events that happened
>
> To make everything clearer in my mind, I wrote my own implementation of 
> something similar to what you did. You can find it here:
>
> https://github.com/marcosh/elm-escqrs/blob/master/EsCqrsMain.elm
>
> It should be just a functional transposition of a standard es/cqrs 
> architecture (I actually used also es/cqrs jargon), adacted to the Elm 
> Architecture.
>
> I'd really like to know what you think of it. Let me know if something is 
> not clear enough
>
> On Sunday, August 14, 2016 at 7:37:25 AM UTC+2, Kasey Speakman wrote:
>>
>> So, I made a Gist 
>>  of 
>> the helper stuff which splits Facts and Acts. I call the helper Factor... 
>> (Fact or Act ~=> Factor). There is a subsequent comment with an example 
>> program explaining the helper's usage.
>>
>>

-- 
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: More thorough side-effect isolation

[Marco Perone]

Hi!

I was eventually able to read carefully the thread and give some thoughts 
about it.

@kasey, I had a look to your Gist and it looks really interesting! Some 
notes about it:

- I think it would be better to store in the parameter of the Fact's the 
increment, and not the state of the application. It looks to me that you 
are mixing two concerns, i.e. the state of the applications and the events 
that happens to it

- if I'm not mistaken, from you implementation it seems that only Act's 
(and not Fact's) can generate new Cmd's. I think that is some applications 
there could be the need to react automatically with a new Cmd to some 
events that happened

To make everything clearer in my mind, I wrote my own implementation of 
something similar to what you did. You can find it here:

https://github.com/marcosh/elm-escqrs/blob/master/EsCqrsMain.elm

It should be just a functional transposition of a standard es/cqrs 
architecture (I actually used also es/cqrs jargon), adacted to the Elm 
Architecture.

I'd really like to know what you think of it. Let me know if something is 
not clear enough

On Sunday, August 14, 2016 at 7:37:25 AM UTC+2, Kasey Speakman wrote:
>
> So, I made a Gist 
>  of 
> the helper stuff which splits Facts and Acts. I call the helper Factor... 
> (Fact or Act ~=> Factor). There is a subsequent comment with an example 
> program explaining the helper's usage.
>
>

-- 
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] We need a clearer story on architecture

[Oliver Searle-Barnes]

I've been using Elm for about 4 weeks now and having generally been loving 
it. An area that I'm really having trouble with though is architecture. The 
basic TEA is a fantastic foundation but the guidelines are really very 
limited with regards to requirements of a typical SPA. 

* Components - the best advice I've heard is to extract view/model/update 
separately, as we've seen with elm-mdl this only goes so far though. In the 
end every large application is going to end up with it's own framework 
similar to elm-mdl so this seems to be an issue that needs to be resolved 
somehow. 
* Separation between view model(component state) and application model 
(records from the server) - previously I've always had these two separated 
which has meant that I can have multiple views updating the same server 
records. 
* Services - when I've had cross-cutting concerns I would typically manage 
them in a service tier, e.g. I'm using websockets and want to update the 
view optimistically. Managing the optimistic vs confirmed state isn't 
something that I'd expect to have abstracted away from the view.

I'm not really looking to resolve these issues here but I do feel like the 
community is going in circles. Every day we hear the same questions like 
"how does parent-child communication work?" but the advice that is given is 
different depending who you ask (and always feels unresolved). 

A general concern I have is that the impression that's given is that 
abstraction is treated as something which should be avoided. This seems 
unworkable for large SPAs. It gives the impression that perhaps no one in 
the Elm community is really building large applications. 


These are my concerns and issues, what I'm really looking for though is an 
approach to move things forward. Given that there are existing frameworks 
with well understood architectures I wonder if we should work on guides of 
the form Elm for React users or Elm for Ember users and try to translate 
the concepts from those frameworks into practical solutions within Elm. I 
think this would help clarify the advice and perhaps uncover areas where we 
need to give some more thought.

-- 
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: Elm UI boilerplate

[OvermindDL1]

On Wednesday, August 17, 2016 at 9:07:35 AM UTC-6, Peter Damoc wrote:
>
> The elm-parts Msg is defined as: 
>
> type Msg c = 
>   Msg (c -> (Maybe c, Cmd (Msg c)))
>
> This is why I consider the "without parts" the pure TEA. 
>

True, I can see that yeah, unsure of a better way off hand either...


 On Wednesday, August 17, 2016 at 9:07:35 AM UTC-6, Peter Damoc wrote:

> This is another reason to have this discussion. 
> Søren did the best he could with the technology he had at his disposal. 
> He has created something that removes some of the pain but introduces 
> other issues like the manual identity management that can lead to issues 
> like the one you describe. 
>
> There has to be a better solution. 
>

I keep trying different styles of things, but I can never seem to come up 
with one that works very well while allowing arbitrary expansion of view 
elements without huge amounts of highly duplicated but not-quite code that 
cannot be reduced due to lack of functionality in Elm as of yet.  Really do 
need 'some' method though...

-- 
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 do I write an elm-check producer for a recursive data structure?

[Max Goldstein]

Glad to hear it's working. I opened an issue to add almostIssue so the idea 
doesn't get lost.

-- 
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: Elm UI boilerplate

[Peter Damoc]

On Wed, Aug 17, 2016 at 5:40 PM, OvermindDL1  wrote:

> I do not consider elm-parts to not be pure TEA, I just consider it to make
> view/state combinations that are ID'd for separation, but I still consider
> it pure TEA.
>


Evan said in the sortable table Readme
:

> One of the core rules of The Elm Architecture is never put functions in
> your Model or Msg types.


The elm-parts Msg is defined as:

type Msg c =
  Msg (c -> (Maybe c, Cmd (Msg c)))

This is why I consider the "without parts" the pure TEA.



> However, there is one niggle of irritant of elm-mdl/elm-parts that I am
> not sure can be worked around, and that is its 'ID', the fact you have to
> manually manage the number means that you can add in duplicates
> accidentally (such as duplicating a line to add something).  However we
> need the ID's to keep things not only distinct but to refer back to them as
> well.  What we need is some way to ensure there are no duplicates on
> generation and if so log a warning or something (there are also cases where
> duplicates are needed).  Currently this is not possible without having a
> parent view that walks the entire virtual node try via a to/from json hack
> or so again, which is painful and not done for possible breakage reasons in
> the future.
>

This is another reason to have this discussion.
Søren did the best he could with the technology he had at his disposal.
He has created something that removes some of the pain but introduces other
issues like the manual identity management that can lead to issues like the
one you describe.

There has to be a better solution.




-- 
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: Design of Large Elm apps

[OvermindDL1]

On Wednesday, August 17, 2016 at 5:25:45 AM UTC-6, Oliver Searle-Barnes 
wrote:

> See elm-mdl for example, what are your thoughts on the elm-parts approach?
>

I quite like the elm-mdl/elm-parts approach, very extensible.  Do note that 
elm-mdl only uses elm-parts for parts that hold any kind of state (using 
'render' as its view function call).  If it is pure view then it does not 
use elm-parts (and uses 'view' as its view function call) in the general 
case.

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

[Peter Damoc]

There is a growing interest in elm-mdl lately and this brings into focus
the issue of boilerplate when dealing with custom UI.

In yesterday's Elm Remote Meetup, Søren mentioned that he hasn't met anyone
who uses elm-mdl without the parts.

Here is a very simple form with and without the boilerplate:
https://github.com/pdamoc/elm-boilerplate-example

The pure TEA UI (without parts) is around 50% more lines of code with zero
added benefit.
As I was porting the parts code to the non-parts form I realized that there
were some opportunities for errors due to repetitiveness. I basically copy
and pasted some of the code.

I am all for using the current recommendations but there are specific cases
like the implementation of a dynamic UI toolkit where the current
recommendations produces lower quality code.


-- 
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] Anyone using Firebase 3.0 with Elm 0.17?

[Thomas Weiser]

I have sketched an API for an effect manager module and will discuss it 
soon with you all.


First I will target Firebase's existing realtime database and 
authentication API before switching to Firebase 3.0 and its new 
authentication API. I have not looked into Firebase's new storage API yet.


Sorry for the long delay. Time is very limited atm. Will be better from 
September onwards.



On 17.08.2016 09:29, Corey Trampe wrote:
I've been watching ElmFire for the 0.17 update 
, and Firebase 3.x 
support , but I 
guess Thomas Weiser hasn't had time to work on it. (And I'm not here 
to complain about free software! Thanks, Thomas, for sharing your good 
work.)


But in the meantime... is anyone using Firebase 3.x with Elm 0.17?

Are you using ports, or a custom effect manager?

How's it working out? Can you share what you've learned?

( I need the new API for Storage 
. )


Thanks!


--
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: Design of Large Elm apps

[Oliver Searle-Barnes]

Thanks, this is really practical advice.


The first three things you should reach for are, in no particular order:
>
>1. Splitting view into smaller functions (without reorganizing Model 
>or update)
>
>
>1. Splitting Model into smaller values (without reorganizing view or 
>update)
>
>
>1. Splitting update into smaller functions (without reorganizing Model
> or view)
>
>
I can see how this fits really well for building whole pages, where reuse 
isn't a concern. There are a couple of scenarios where I'm still left 
pondering though:

1) reusabled UI components

See elm-mdl for example, what are your thoughts on the elm-parts approach?

2) services 

e.g. I'm using websockets to communicate with the server, in my previous 
experience I would have implemented a Store of some sort which took care of 
communication with the server and allowed the view layer to just worry 
about asking for information and sending mutations. 

Currently I've implemented a Store as a TEA component without a view. This 
works but I'm left with this nagging doubt that I'm simply supplanting an 
ember-like approach into my new Elm app :) 

Just to add some weight to my feeling that there needs to be a layer 
between the view and the server I'm also intending to add management of 
optimistic updates --- so updates will initially be applied directly to the 
model optimistically, then once all updates have been confirmed with the 
server the optimistic state is thrown away and replaced by a version which 
has been updated with messages received only from the websocket (which is a 
mix of updates from both the local user and any other users connected to 
the same channel --- I'm using Phoenix).

Would you agree that a layer between the view and websocket makes sense 
here? If so how would you organise that? Does the approach I've taken, to 
implement it as a TEA component make sense or perhaps there's another 
approach that I haven't 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.

Re: [elm-discuss] Elm passing initial value

[Janis Voigtländer]

That said, it’s strange the compiler error pointed you to
http://guide.elm-lang.org/effect_managers/. It should have pointed you to
http://guide.elm-lang.org/interop/javascript.html instead.

https://github.com/elm-lang/elm-compiler/pull/1463
​

2016-08-17 12:53 GMT+02:00 Janis Voigtländer :

> The story around this has changed.
>
> If you want to pass some data into Elm from JS once, on initialization,
> you are now served by: http://package.elm-lang.org/
> packages/elm-lang/html/1.1.0/Html-App#programWithFlags
> ​
>
> 2016-08-17 12:48 GMT+02:00 Wei Tang :
>
>> Hi,
>>
>> I'm trying to define an "incoming port" that will *only be called once*
>> when the app starts. I read some tutorials (http://danielbachler.de/2016/
>> 02/26/ports-in-elm.html) and it says I can define a "non-signal" type
>> port to do this. However, I get this error:
>>
>> 8| port graphName : String
>>^^^
>> You are saying it should be:
>>
>> String
>>
>> But you need to use the particular format described here:
>> 
>>
>> But I didn't find any useful information in the provided links.
>>
>> Any help would be appreciated.
>>
>> -- Wei
>>
>> --
>> 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] Elm passing initial value

[Janis Voigtländer]

The story around this has changed.

If you want to pass some data into Elm from JS once, on initialization, you
are now served by:
http://package.elm-lang.org/packages/elm-lang/html/1.1.0/Html-App#programWithFlags
​

2016-08-17 12:48 GMT+02:00 Wei Tang :

> Hi,
>
> I'm trying to define an "incoming port" that will *only be called once*
> when the app starts. I read some tutorials (http://danielbachler.de/2016/
> 02/26/ports-in-elm.html) and it says I can define a "non-signal" type
> port to do this. However, I get this error:
>
> 8| port graphName : String
>^^^
> You are saying it should be:
>
> String
>
> But you need to use the particular format described here:
> 
>
> But I didn't find any useful information in the provided links.
>
> Any help would be appreciated.
>
> -- Wei
>
> --
> 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.

[elm-discuss] Elm passing initial value

[Wei Tang]

Hi,

I'm trying to define an "incoming port" that will *only be called once* 
when the app starts. I read some tutorials 
(http://danielbachler.de/2016/02/26/ports-in-elm.html) and it says I can 
define a "non-signal" type port to do this. However, I get this error:

8| port graphName : String
   ^^^
You are saying it should be:

String

But you need to use the particular format described here:


But I didn't find any useful information in the provided links.

Any help would be appreciated.

-- Wei

-- 
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 do I write an elm-check producer for a recursive data structure?

[John Watson]

@Max

Many thanks.  I upgraded the elm-test runner and all was fine.  Fuzzers do 
the trick when you limit the depth of recursion as in your example.  Just 
upgraded to 2.0.1 and the shrinker seems to be working much better now.

One thing I'd like to have added (if possible)

almostEqual : Float -> Float -> Expectation





On Saturday, 13 August 2016 21:52:19 UTC+1, Max Goldstein wrote:
>
> @John Yes, elm-check was deprecated earlier this will. You almost 
> certainly have an old version of the elm-test shell utility; "elm test 
> --version" should yield 0.17.1. If it doesn't,
>
> npm uninstall -g elm-test
> npm install -g elm-test
>
> "elm test init" will create the directory *tests* which will contain a 
> runner file Main.elm that you don't need to touch, and Tests.elm where you 
> put your tests.
>
> One of the big improvements over elm-check is that a fuzz test that fails 
> many times still counts as one failing test. This wasn't possible using 
> *evidenceToTest*.
>

-- 
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: text editor for Elm + GLSL

['Rupert Smith' via Elm Discuss]

On Tuesday, August 16, 2016 at 6:54:38 PM UTC+1, Nick H wrote:
>
> The list has been talking about text editors lately. For those of you who 
> use elm-webgl, is there a text editor that can properly format GLSL code 
> blocks?
>
> fragmentShader : Shader {} Uniform Varying
>> fragmentShader =
>> [glsl|
>>  precision mediump float;
>>  varying vec4 fragColor;
>>
>>  void main () {
>>  gl_FragColor = fragColor;
>>  }
>> |]
>>
>
> I am an Emacs user. As has been mentioned before, Emacs elm-mode 
> indentation is busted. This isn't a problem for me most of the time, thanks 
> to elm-format. But elm-format does not touch GLSL blocks, so I'm stuck 
> fixing the indentation by hand.
>
> Any suggestions? Thanks!
>

Emacs multi-mode ? :-) sorry couldn't resist...

Does elm-format leave strings alone? In which case you could put the glsl 
code in a string constant? 

-- 
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: Design of Large Elm apps

['Rupert Smith' via Elm Discuss]

On Thursday, August 11, 2016 at 2:38:45 AM UTC+1, Richard Feldman wrote:
>
> What were the cases where it was a good idea? You found some genuinely 
>> re-usable component in your code base?
>>
>
> The first example that comes to mind is when we had a "school search" 
> modal dialog on a dashboard that only displayed occasionally: once on 
> signup, and then again if you wanted to edit the school associated with 
> your account.
>
> It had a ton of self-contained logic - 20 fields in the Model, talking 
> back and forth to an Algolia API, etc - that involved a lot of code which 
> had absolutely nothing to do with the rest of the page. No matter what the 
> user did on the modal, it didn't affect any other part of the UI. So there 
> was almost nothing to communicate to the parent (pretty much just "hey, the 
> user clicked the Close button") and giving it its own separate Model, its 
> own separate View, and its own separate Update moved a lot of code out of 
> all three places for the parent.
>
> In a lot of ways, needing a lot of parent-child communication is probably 
> a red flag that these are too tightly coupled for a parent-child 
> relationship to be a good idea. :)
>

This sounds like Parna's principles of modular design and not wildly 
different to applying those principles in say OO design. If there is too 
much communication between two classes, the 'feature envy' suggests that 
the abstraction is not quite right. A better design needs to identify a 
class with enough self-contained state and/or logic to justify its 
existence. That said, in classic imperative OO design I reach for the 
modular design and re-use toolbox pretty quickly, it is almost second 
nature.

It is interesting what you are saying about not reaching for a modular 
design so quickly with elm, but to explore the other options first. For 
example, I am already finding that the View will fairly quickly throw up 
re-usable bits and pieces - perhaps a div that I wrap various UI elements 
in to give them some common look and feel. This can be abstracted out by 
writing it as a function, and if that function is particularly useful it 
can be pulled up into a ViewUtils.elm for re-use. Functional programming 
itself offers a lot of possibilities that imperative OO does not.

So I am reading your advice as 'explore what you can do with functional 
programming before you explore what you can do with modularizing the elm 
architecture'. 

-- 
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] Anyone using Firebase 3.0 with Elm 0.17?

[Corey Trampe]

I've been watching ElmFire for the 0.17 update 
, and Firebase 3.x 
support , but I guess 
Thomas Weiser hasn't had time to work on it. (And I'm not here to complain 
about free software! Thanks, Thomas, for sharing your good work.)

But in the meantime... is anyone using Firebase 3.x with Elm 0.17?

Are you using ports, or a custom effect manager?

How's it working out? Can you share what you've learned?

( I need the new API for Storage . 
)

Thanks!


-- 
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: Child model change propagation problem in elm architecture

[Jacky]

The example is simplified but I think in reality there may comes a case in
which you need to group certain parts into components.
I guess we are also used to partition the app into different parts, usually
starting by watch the mockups.
Maybe we should do a little translation from the "dump and smart" component
concept in react:
  - dump ==> pure function
  - smart ==> elm component with its own model, view, update

On Wed, Aug 17, 2016 at 2:52 PM, Kasey Speakman 
wrote:

> Why were two inputs arbitrarily made into a component? If you're not
> reusing it, then why bother? In the broader picture, you are trying to
> apply object orientation (encapsulation), and it doesn't fit. It can't fit
> because the model does not ultimately belong to the component.
>
> If you need to compose certain elements together for reuse, consider
> making it a view-only widget (a pure function), passing in the data and
> message constructors it needs to fulfill its purpose.
>
> http://elm-lang.org/blog/blazing-fast-html#reusable-widgets
>
> The thread Magnus linked is a good read as well.
>
>
> On Tuesday, August 16, 2016 at 9:51:15 PM UTC-5, Jacky See wrote:
>>
>>
>> Hi, I'm a new comer to elm. I try to build application using elm and have
>> some problem on component.
>>
>> Suppose I'm building an BMI calculator, initially I have a model
>>
>> type alias Model = { weight:Int, height:Int }
>>
>> The rendering is just an two input[type=number].
>> The result is rendered by a pure function at the main app:
>>
>> calclulate model =
>>   let
>> h = (toFloat model.height) / 100
>> w = toFloat model.weight
>>   in
>> toString (round (w / (h*h)))
>>
>>
>> One day a decision made to change those two inputs into a component of
>> its own (BmiConfig).
>> So the models become
>>
>> --at main app
>> type alias Model = { bmiConfig: BmiConfig.Model ... }
>>
>> --at BmiConfig
>> type alias Model = {weight:Int, height:Int}
>>
>> We need to to the work of connecting Msg, etc. The calculate function
>> becomes
>>
>> calclulate model =
>>   let
>> h = (toFloat model.config.height) / 100
>> w = toFloat model.config.weight
>>   in
>> toString (round (w / (h*h)))
>>
>>
>> Another a change comes and requesting add +/- button to the number input.
>> We try to make a small generic component NumberInput. Models become:
>>
>> --at main app
>> type alias Model = { bmiConfig: BmiConfig.Model ... }
>>
>> --at BmiConfig
>> type alias Model = {weight:NumberInput.Model,
>> height:NumberInput.Model}
>>
>> --at NumberInput
>>  type alias Model = {value:Int, max:Int, min:Int,  }
>>
>> The calculate function needs to be changed again:
>>
>> calculate model =
>>   let
>> h = (toFloat model.config.height.value) / 100
>> w = toFloat model.config.weight.value
>>   in
>> toString (round (w / (h*h)))
>>
>> It seems to me that every refactoring to extract component would lead to
>> a propagation
>> of change all the ways from child to its parents. Parents need to know
>> the data
>> structure of child to do calculation too. Is that the correct way of
>> applying the elm architecture?
>> Have I missed something?
>>
>>
>>
>>
>> --
> 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/mYGK12WCiew/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.
>



-- 
Best Regards,
Jacky See

-- 
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: Child model change propagation problem in elm architecture

[Kasey Speakman]

Why were two inputs arbitrarily made into a component? If you're not 
reusing it, then why bother? In the broader picture, you are trying to 
apply object orientation (encapsulation), and it doesn't fit. It can't fit 
because the model does not ultimately belong to the component.

If you need to compose certain elements together for reuse, consider making 
it a view-only widget (a pure function), passing in the data and message 
constructors it needs to fulfill its purpose.

http://elm-lang.org/blog/blazing-fast-html#reusable-widgets

The thread Magnus linked is a good read as well.

On Tuesday, August 16, 2016 at 9:51:15 PM UTC-5, Jacky See wrote:
>
>
> Hi, I'm a new comer to elm. I try to build application using elm and have 
> some problem on component.
>
> Suppose I'm building an BMI calculator, initially I have a model
>
> type alias Model = { weight:Int, height:Int }
>
> The rendering is just an two input[type=number].
> The result is rendered by a pure function at the main app:
>
> calclulate model = 
>   let 
> h = (toFloat model.height) / 100
> w = toFloat model.weight
>   in
> toString (round (w / (h*h)))
>
>
> One day a decision made to change those two inputs into a component of its 
> own (BmiConfig). 
> So the models become
>
> --at main app 
> type alias Model = { bmiConfig: BmiConfig.Model ... }
>
> --at BmiConfig
> type alias Model = {weight:Int, height:Int}
>
> We need to to the work of connecting Msg, etc. The calculate function 
> becomes
>
> calclulate model = 
>   let 
> h = (toFloat model.config.height) / 100
> w = toFloat model.config.weight
>   in
> toString (round (w / (h*h)))
>
>
> Another a change comes and requesting add +/- button to the number input. 
> We try to make a small generic component NumberInput. Models become:
>
> --at main app 
> type alias Model = { bmiConfig: BmiConfig.Model ... }
>
> --at BmiConfig
> type alias Model = {weight:NumberInput.Model, height:NumberInput.Model}
> 
> --at NumberInput
>  type alias Model = {value:Int, max:Int, min:Int,  }
>
> The calculate function needs to be changed again:
>
> calculate model =
>   let 
> h = (toFloat model.config.height.value) / 100
> w = toFloat model.config.weight.value
>   in
> toString (round (w / (h*h)))
>
> It seems to me that every refactoring to extract component would lead to a 
> propagation
> of change all the ways from child to its parents. Parents need to know the 
> data
> structure of child to do calculation too. Is that the correct way of 
> applying the elm architecture?
> Have I missed something?
>  
>
>
>
>

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