Re: [elm-discuss] Re: Comments on the TEA Components package

[Richard Feldman]

>
> We did spend the first 6 months or so of our project following the advice 
> to not use nested TEA components. Our experience was that the perceived 
> complexity of the app grew exponentially to the point where it was 
> difficult to make progress. We refactored into a nested TEA structure and 
> are far happier since (the change was made at the start of the year).
>

Fair enough!

*Reusable view components* 
> We view these as distinct from the mini-apps that I mentioned earlier.  


Ahh, right, this "mini-apps" design sounds familiar to me. I think I 
remember talking to you about this awhile back - as I recall, you had some 
really interesting business requirements in terms of how and when parts of 
the page were loaded.

If you have time, would you mind describing how the app works?

-- 
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: Comments on the TEA Components package

[Oliver Searle-Barnes]

> I have not seen the reverse happening.

We did spend the first 6 months or so of our project following the advice 
to not use nested TEA components. Our experience was that the perceived 
complexity of the app grew exponentially to the point where it was 
difficult to make progress. We refactored into a nested TEA structure and 
are far happier since (the change was made at the start of the year). I'll 
try to summarise the areas where we saw an improvement. (note I've used the 
term TEA component for lack an alternative -- triplet doesn't really cover 
it as we've added additional functions into what we think of as mini-apps).

*Msgs*
The Msgs for a part of the UI were only valid once that part of the UI was 
actually loaded. Prior to nesting we had to handle the possibility of Msgs 
being created that in fact couldn't exist at a particular point in time. 

*Models*
Similar to Msgs, the state for a particular part of the UI was only present 
if that part of the UI was actually initialised. Using a flattened 
structure this led to a lot of Maybes that could be replaced by a single 
Maybe or Dict (in the case that multiple versions of that part of the UI 
could be loaded at the same tie). While it isn't necessary to introduce a 
TEA component to do this, you are already another step down the road to a 
TEA component once you do this. 

*Declarative data loading* 
Each TEA component can now specify which data it requires and it's made 
available/kept updated when that component is active. Active here meaning 
that the component has been initialised but may or may not currently be 
visible. Having this consistent approach to data synchronisation has made 
it easier to understand the data lifecycle for a particular part of the UI.

*Synchronisation of scroll state and focus* 
Each of our nested components now has a syncDom hook which is used to 
synchronise aspects of the DOM which can't be handled declaratively. Being 
able to target a TEA component rather than the whole app or e.g. a 
particular element's scroll state has proven to be a practical level of 
granularity.

*Reusable view components* 
We view these as distinct from the mini-apps that I mentioned earlier. The 
approach elm-sortable-table uses shifts some of the burden of state 
management into the client of the package. In it's case this is a good 
tradeoff. In other cases, when a component has several pieces of view state 
for instance, pushing this out to the consumer ends up with copy/pasted 
code that has all the pain that you'd expect. Sometimes the client has no 
business touching the state at all, e.g. the open/closed state of a 
dropdown menu for instance. In that case the menu is responsible for when 
it's open/closed and it needs to manage this when a user for instance 
clicks on a link in the menu (the menu needs to be closed before handling 
the click).

*Code comprehension* 
Developers are finding it far easier to navigate the codebase. They're now 
able to work on a particular TEA component and the amount of code they have 
to grok before they can get started is far smaller. Prior to introducing 
the nested structure the feedback from new developers was that they felt 
lost at sea and overwhelmed by the amount of code they had to wade through. 
Generally excuses were made and they avoided working on the Elm app. Now 
that we've moved to a nested structure they're able to concentrate on a 
small part of the app and get up to speed/make changes easily.

Our experience has been that TEA component concept that was encouraged with 
0.17 has it's place in SPAs. It appears other teams building SPAs have had 
similar experiences (although I'm not sure whether they've experimented 
with the flat approach). As Mark has mentioned it does at least provide an 
architecture which new Elm developers building SPAs can get started with. 
There may well be a flat approach that addresses some of the concerns that 
I've mentioned. Currently though it seems a somewhat illusive approach, if 
it's to be encouraged then there needs to be some more concrete advice 
regarding how to implement it. That said, aside from a little boilerplate 
(which is minimal by comparison to the actual app code) we really haven't 
felt any desire to move away from the nested TEA structure.


On Thursday, 20 April 2017 03:09:47 UTC+2, Richard Feldman wrote:
>
> The structure camp says (in many more words) "I've seen your alternative 
>> and it isn't a real alternative. It's a pathway that decades of software 
>> industry experience indicates leads to creating big balls of mud."
>>
>  
> This idea would hold more water if people hadn't tried what you're telling 
> them Decades Of Experience Dictates Can't Possibly Work and found that it 
> actually worked great when they tried it.
>
> The old "who are you gonna believe, me or your lying eyes?" argument does 
> not have a great track record.
>  
>
>> To the extent that we live in a world where we all say "you're free to 
>> 

[elm-discuss] A Code Teaching Analogy

[Duane Johnson]

I once tried teaching several friends to code who'd never written a line
before.

I thought the best way would be to introduce each keyword in the language,
one at a time, and explain what they do and how good programmers use them.
One of the keywords was "for", as in the "for loop". I was baffled that my
friends were kind of impatient and frustrated with learning about "for"
loops.

Instead, I found that each of them would copy/paste code. If they needed to
print the numbers 1 through 10 on the screen, it was easier for them to
grab the tool they knew how to use: copy, paste. They would paste ten lines
of "print" statements and change the text inside the quotes:

print "1"
print "2"
print "3"
etc.

When one of my friends wanted to write out all of the ASCII characters,
however, he balked at the amount of code it was going to take. He'd have to
copy-paste nearly 200 lines and individually edit them.

That's when I introduced the "for" loop again, and suddenly I was hailed as
a hero! Looping was suddenly awesome. Pain was relieved. A few sweet lines
of code were written. We rejoiced.

But on separate occasions, my other friends still didn't understand how
awesome for loops were. I could have been frustrated by that, but I soon
realized that everyone is basically the same: we reach for the tools we
know, until they're painful, and then we look for solutions.

I wish the Elm learning experience could be like this for incoming
javascript developers.

-- 
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: Task ports: A proposal to make it easier to integrate JS with Elm.

[Tim Stewart]

Very well put Mark.

Regarding Nicholas' advice on "The process"

> 6. Do things in life that make you happy. If it upsets you that Elm lacks 
something you think is super important, maybe take a break and come back 
later.

That's what I've done. I'm back in JS land and Getting Things Done. Elm's 
lack of a simple mechanism for interaction with external APIs (other than 
pub/sub style APIs, which it does well, but they are the minority) limits 
its practical application. The proposition that the tiny core Elm team will 
deliver built-in integration to all APIs in every JS runtime context 
(Electron? Cordova? Lambda? Chrome Extension? React Native? Arango? 
Espruino? ...) is clearly not realistic. 

On Thursday, April 20, 2017 at 4:07:47 AM UTC+10, Mark Hamburg wrote:
>
> Since the call is for concrete use cases, here is one: Reading from local 
> storage.
>
> My program wants to cache various things in local storage or for the 
> purposes of this example it wants to read from various locations in local 
> storage to get the values needed at various points in the model/UX. If we 
> didn't use local storage and just used HTTP, we would generate HTTP 
> requests at the points where we needed the information and using Elm 
> message routing get the results delivered back. We would like to do the 
> same thing with local storage as a cache — possibly followed by an HTTP 
> fallback if we found nothing in local storage but that's beyond the scope 
> here.
>
> The analogous API to the HTTP case would be something like:
>
> get : (Result Error Json.Decode.Value -> msg) -> String -> Cmd msg
>
>
> Or to make it more composable — cough, tasks v commands, cough — we might 
> have:
>
> getTask : String -> Task Error Json.Decode.Value
>
>
> Given that the Elm local storage effects manager seems to be on indefinite 
> hold, we need to use ports. So, what does it take to do this using ports?
>
> Command ports don't return results. Subscription ports don't convey 
> information to the JavaScript side. So, we have to use a pair of them. A 
> command to trigger work on the JavaScript side and a subscription to 
> receive values back. But how do we match results coming back with requests 
> coming in? How do we tag those results appropriately for delivery?
>
> There would seem to be two options:
>
> 1. For every request we need to make, create a separate pair of ports. 
> Now, we don't need to pass in the key string because the key is built into 
> the port identity. In fact, it would be bad to pass in the key string since 
> that would reintroduce the question of which response goes with which 
> request. This approach will work if we can statically enumerate ahead of 
> time all of the keys we are interested in AND we are prepared to write 
> JavaScript handler code for each and every request. This might be viable 
> for the big flat applications that some people like to advocate but it's a 
> pretty messy maintenance situation and it breaks the moment we can't 
> statically enumerate the keys of interest.
>
> 2. When we send a request in, we tag it with an identifying number and 
> maintain a dictionary mapping those id's to tagger functions. The 
> JavaScript side includes the id in its response — basically the same thing 
> Phoenix push messages do — and the subscription port feeds into logic that 
> looks up the id and tags and delivers the result. Those of you who are 
> horrified at the thought of storing functions in the model should perhaps 
> stop right here because that id to tagger function dictionary is doing 
> exactly that. But even if one gets beyond that, note that this approach 
> won't work just like HTTP because we will need at some point before this 
> becomes a command to update the delivery map. That can either happen by 
> replacing commands with requests or by allowing arbitrary update code to 
> touch the shared global id generator and delivery map. Neither approach is 
> as straightforward as the HTTP case.
>
> This could be addressed by extending command ports to allow them to return 
> responses but if we're doing that, why not just make them composable and 
> generate tasks that take a Json.Encode.Value as input and return a Task 
> PortError Json.Decode.Value (where PortError might just be another 
> Json.Decode.Value or it might be some other response structure that could 
> reflect other implementation errors TBD):
>
> port get : Json.Encode.Value -> Task Task.PortError Json.Decode.Value
>
>
> Now, I can wrap this up in code to do the encoding of strings to JSON 
> (trivial) and map the resulting task result to do any appropriate decoding 
> and delivery.
>
> One could argue that this would all be handled in the local storage effect 
> manager thereby rendering this example moot. But as noted above, that 
> effects manager seems to be on indefinite hold. Furthermore, local storage 
> was just a convenient and simple example. The exact same arguments could 
> apply to almost any storage 

Re: [elm-discuss] Re: Comments on the TEA Components package

[Richard Feldman]

>
> Sorry again for confusing.
>

It's all good! :)

You were super polite and respectful throughout.

-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
> The structure camp says (in many more words) "I've seen your alternative 
> and it isn't a real alternative. It's a pathway that decades of software 
> industry experience indicates leads to creating big balls of mud."
>
 
This idea would hold more water if people hadn't tried what you're telling 
them Decades Of Experience Dictates Can't Possibly Work and found that it 
actually worked great when they tried it.

The old "who are you gonna believe, me or your lying eyes?" argument does 
not have a great track record.
 

> To the extent that we live in a world where we all say "you're free to 
> develop software however you see fit", we can often take the attitude. 
> "That's interesting. It wouldn't work for me but I see why you are making 
> those choices."
>

It seems that from your perspective, this is an intellectual exercise with 
low stakes. I see this as a discussion that has great potential to cause 
pain, because I've seen a lot of pain result from past discussions on this 
topic.

A lot of people follow what you're advocating and then end up reporting 
that they had a really bad experience with it. I ask where they got the 
idea that this would be a good approach to follow, and they point to a blog 
post someone wrote, or a discussion thread where nobody stood up for the 
simpler alternative. Then I point them to advice like this 
,
 
and I get a lot of people coming back to thank me afterwards, saying they 
got out of the "component mindset" and now they're happy with how their 
code scales.

*I have not seen the reverse happening.* I don't see people saying "I 
decided to refactor everything to be based around model/view/update 
triplets just because, and I was much happier with my code afterwards." 
Obviously it's not impossible to follow your advice and have a fine time 
anyway, but I can confirm at least one case - myself - where someone 
consciously shifted towards the "component mindset" (before it had that 
name) and hated working with the result so much, he halted work on the 
project until he could refactor it back to the old way.

You keep acting like this is unexplored territory even though *it has been 
explored by many people.*

I'm not going to pretend discussing things in a public form has no 
consequences for beginners who come across it later. Call me a 
bold-text-using verbal ruffian if you like. If I can pull people away from 
a cliff, I intend to. :)

-- 
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: Comments on the TEA Components package

[Yosuke Torii]

I just read the whole conversation on Slack and realized what I said here
was somewhat pointless. I apologize for not reading the context.

So Marek's library is for organizing entire app, not about using external
library. If so, Richard's answer on reddit seems best fitted. About the
external libraries that have their own state, it is already answered well.

rtfeldman [3 days ago]
> the difference is that `thebritician/elm-autocomplete` is managing its own
> state because there is absolutely no possible other way to implement that
> library
> it's the last resort, not the default


I agree. It seems true from my experience too. Sometimes model, update, msg
and view are all together. But it is a special case. elm-component's API is
telling beginners as if they should always be together. Okay I completely
understand the context. It must be an anti-pattern!

Sorry again for confusing.


2017-04-20 9:21 GMT+09:00 Richard Feldman :

>
>> I thought I've understood this but I'm more and more confused by what
>> you're saying:
>>
>>> Crucially, between 0.16 and today, *we learned that a Model-View-Update
>>> triplet is the wrong unit of composition for Elm applications.*
>>
>> init update and subscribe are actually function. Looks like I still miss
>> something. Are you trying to say that Cmd.map is not function or what?
>>
>
> What I'm saying is that *individual functions*, as opposed to *a group of
> functions and data structures* (model, view, update, msg, etc) is the
> right unit of composition.
>
> In the example earlier in this thread
> , I
> showed an API for a reusable checkbox using a single function. I then
> showed an alternate API that resulted from the mindset that a *group* *of
> functions and data structures* (model, view, update, msg, etc) should be
> the atomic *unit of composition* - the notion that "you should build Elm
> applications by composing together model/view/update triplets" which I've
> seen cause pain. I pointed out that this mindset led to an overengineered
> checkbox API that was unnecessarily complex.
>
> Does that clarify?
>
> on different topic:
>>
>>  many of us have tried this, and found that composing individual
>>> functions was both simpler and consistently led to a much better experience.
>>
>>
>> Not even pointing out all nonsense: I just don't see any of them here
>>  just
>> yet. I hope they will shop up.
>>
>
> I'm not going to dig up a bunch of peoples' names and pester them to
> testify that this actually happens. :P
>
> Please don't start sending links to same Reddit thread once again.
>
>
> I'm doing that so that if beginners stumble on this thread and skim
> through it, they don't have to dig for what I'm recommending. :)
>
> --
> 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/Lo6bG96zotI/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: Comments on the TEA Components package

[Richard Feldman]

>
>
> I thought I've understood this but I'm more and more confused by what 
> you're saying:  
>
>> Crucially, between 0.16 and today, *we learned that a Model-View-Update 
>> triplet is the wrong unit of composition for Elm applications.*
>
> init update and subscribe are actually function. Looks like I still miss 
> something. Are you trying to say that Cmd.map is not function or what?
>
 
What I'm saying is that *individual functions*, as opposed to *a group of 
functions and data structures* (model, view, update, msg, etc) is the right 
unit of composition.

In the example earlier in this thread 
, I 
showed an API for a reusable checkbox using a single function. I then 
showed an alternate API that resulted from the mindset that a *group* *of 
functions and data structures* (model, view, update, msg, etc) should be 
the atomic *unit of composition* - the notion that "you should build Elm 
applications by composing together model/view/update triplets" which I've 
seen cause pain. I pointed out that this mindset led to an overengineered 
checkbox API that was unnecessarily complex.

Does that clarify?

on different topic:
>
>  many of us have tried this, and found that composing individual functions 
>> was both simpler and consistently led to a much better experience.
>
>
> Not even pointing out all nonsense: I just don't see any of them here 
>  just 
> yet. I hope they will shop up.
>

I'm not going to dig up a bunch of peoples' names and pester them to 
testify that this actually happens. :P

Please don't start sending links to same Reddit thread once again.


I'm doing that so that if beginners stumble on this thread and skim through 
it, they don't have to dig for what I'm recommending. :)

-- 
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-shadertoy updated for Elm-0.18

[Conrad Parker]

Hi,

I've updated elm-shadertoy to work with Elm 0.18. This is a really fun project
and a great way to learn about writing 3D shaders. If you've ever wanted to
play with that side of WebGL please check it out!

https://github.com/kfish/elm-shadertoy

>From the original announce (30 May 2014!):

It is basically a framework for using shaders from shadertoy.com on
webgl surfaces in elm. It replicates some of the inputs that shadertoy
would provide, using elm signals, and adds an elm_FragCoord vector.

Live demo is at: https://kfish.github.io/elm-shadertoy/

This shows some cubes with plasma, flame effects, a voronoi demo and a
raymarching terrain as surface textures. You could imagine the
raymarching scene as the texture on a window in your game world or
something :)

I'd love some help in implementing the "NOT (YET) supported" things
listed on that page, each of which already has an issue set up. In
particular, #3 (adding an input with the current date and clock time)
should be an easy way to get started.

have fun!

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] Discovery: Model /= Database

[Kasey Speakman]

I'm probably slow, but in recent months I've discovered that trying to use 
Elm's Model like a database or cache (as I have previously seen suggested) 
has turned out to be pretty painful for me. An example database-minded 
model where a section could display *either* a list of employees *or* a 
list of courses.

type alias Model =
{ employees : List Employee
, courses : List Course
, loadingError : Maybe Http.Error
, route : MyRoute -- employee or course
}

The problem this runs into is having to worry about state management. I 
have to remember to "reset" or "turn off" things when they are not active. 
As my application grew, I had a lot of problems that boiled down to tedious 
state management details. My cached data didn't turn out to be all that 
useful because I usually had to reload it anyway, in case something changed.

Instead, I have been moving toward the model only representing the current 
state of my UI. The big difference here is the model representing the 
current *visual* elements and their data. This leads more to using union 
types to represent parts of the UI. When you switch to a different case of 
the union type, the data from the previous case is *dropped on the floor*. 
This leaves nothing to remember to "reset". RemoteData is a good 
micro-example of this. If there was an error fetching the data, when the 
user requests the data again, you switch back to Loading, the error message 
is dropped on the floor. No forgetting to hide it.

type RemoteData e a
= NotAsked
| Loading
| Failure e
| Success a

If it is really important to cache the data, I prefer to keep that as a 
persistence concern, not on Model. It can be part of the process for 
retrieving the data to first check my chosen cache before making a request 
for fresh data. For instance, first check local storage before making an 
HTTP call. (Currently, this scenario is easier with Native modules for lack 
of Local Storage API or being able to wait on port subscriptions. But it's 
still doable.)

So working towards a Model reflecting the visuals on the page has been an 
interesting challenge. I'm not claiming it's easier, but so far I've found 
it avoids a class of problems, and has led to some interesting discoveries 
in my own apps. One small example: I realized that my LoggedIn and 
NotLoggedIn routes should actually be separate "apps". Attempts to model 
this in a SPA fashion with the LoggedIn and NotLoggedIn routes as siblings 
always came up with the conundrum: how do I make it a compiler error for 
the model to be in LoggedIn mode but I receive a NotLoggedIn message, or 
vice versa? Even using TEA, I could not avoid this situation. Then I 
realized the only way to do that would be as separate apps. And that it was 
entirely possible to separate them. My "login page" turned out to be an 
entirely self-contained process: the user filling in info, obtaining a 
token, and saving it to local storage.

I post this in the slim hope it is helpful to someone.

-- 
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: Comments on the TEA Components package

[Marek Fajkus]

Richard, 

this is what you said about composing update functions:
 

> I'll reiterate that thinking about application organization as "composing 
> TEA-shaped units" is neither officially recommended nor what Elm is 
> designed for...

 

> > How do you propose to split the functionality one has in a highly 
> complex app with a lot of pages without using those triplets?
> I don't haha...I just defended their use a few posts ago, complete with 
> the specific example of the reusable signup form.


>1. Later 
> I 
>pointed out an example of when it would be useful to use Html.map and 
>Cmd.map to make a reusable signup form, and for that use case it 
>happened to make sense to have a separate model, view, and update.
>
> *I'll use your own words:*
 

> this level of doublespeak is really uncool


I thought I've understood this but I'm more and more confused by what 
you're saying:  

> Crucially, between 0.16 and today, *we learned that a Model-View-Update 
> triplet is the wrong unit of composition for Elm applications.*

repeating one more time:

>
>1. Earlier 
> I 
>said "between 0.16 and today, *we learned that a Model-View-Update 
>triplet is the wrong unit of composition for Elm applications...composing 
>individual functions* was both simpler and consistently led to a much 
>better experience. I've laid out my advice for specifically how to do that 
>here 
>
> 
>."
>
> Well 0.16 -> 0.17 is switch from Effects to Html.program with pure 
individual functions init, update, subscribe, view. Going back to my first 
quote of you. And changing words "TEA-shaped units" with "individual 
functions" we get:  I'll reiterate that thinking about application 
organization as *individual functions* is neither officially recommended 
nor what Elm is designed for...

My point that there's a simple way to scale Elm applications by abstracting 
> at the function level has gone uncontested for awhile in this thread


It did indeed... init update and subscribe are actually function. Looks 
like I still miss something. Are you trying to say that Cmd.map is not 
function or what? 
 
*I'll use your own words:*
 

> this level of doublespeak is really uncool

 
on different topic:

 many of us have tried this, and found that composing individual functions 
> was both simpler and consistently led to a much better experience.


Not even pointing out all nonsense: I just don't see any of them here 
 just yet. 
I hope they will shop up. Please don't start sending links to same Reddit 
thread once again.

I hope you don't think anyone will actually comment this one at all:

I've seen agile teams that could generate lots of small changes but when 
> faced with needing to do something big found themselves profoundly stuck.
> In 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.

Re: [elm-discuss] Re: Comments on the TEA Components package

[Mark Hamburg]

I think we have two general trains of thought regarding development here.

One is YAGNI. Let things grow organically. Refactor when it gets messy.

The other is Build for Success. Over engineer because you will probably end
up shipping the prototype and once you do it will be too late to go back
and do major restructuring.

Each has its place. Each builds for particular outcomes. Each can succeed
or fail in spectacular and unique ways. With great effort, each can emulate
the advantages of the other — ignoring the fact that the advantages are
often in terms of not needing as much effort.

To the extent that we live in a world where we all say "you're free to
develop software however you see fit", we can often take the attitude.
"That's interesting. It wouldn't work for me but I see why you are making
those choices."

Where this turns ugly is when it ceases to be about approaches we
individually find valuable but about how everyone should work.

Let's look at this thread. It was instigated by Marek's "components"
package which got some discussion on elm-dev and which I moved over here to
elm-discuss. The structure camp was essentially looking at this and trying
to judge whether it would help with their own structural work. The YAGNI
camp joined in and said in bold text: "*a Model-View-Update triplet is the
wrong unit of composition for Elm applications."* Not, "I (or we) haven't
found it useful" but "it is wrong". So, now we're off to the races. The
structure camp says (in many more words) "I've seen your alternative and it
isn't a real alternative. It's a pathway that decades of software industry
experience indicates leads to creating big balls of mud." The YAGNI camp
can argue that its statements are strongly worded in the interest of
keeping beginners away from excessive complexity. The structure camp can
argue that it needs to be vocal so that beginners understand the mess that
they may get themselves into on a refactor only as needed path.

Mark

On Wed, Apr 19, 2017 at 2:30 PM, Yosuke Torii  wrote:

> Richard,
>
>
>> Can you think of a way to use this overloaded word in a way where the
>> people in the discussion are not confused by it, even though they think it
>> means different things?
>
>
> I don't know. I just answered the question why I received your message as
> "DIY every time". I'm not looking for the alternative for "component" .
>
> I covered how to grow Elm application code bases
>> ,
>> and Evan covered reuse .
>> What is the remaining problem? :)
>
>
> Again I agree to how to break the monolith and when to do it. But is any
> of those reusable things non-TEA? I find UI libraries at
> packages.elm-lang.com but they are often written in TEA manner. If it is
> not simple, how can they be instead?
>
> Sorry if you have already explained enough. Honestly it is hard to read
> whole of messages, as Noah said.
>
>
> Peter,
>
> The problem is that this approach makes it impossible (as far as I could
>> see) to implement the components that need side effects (like the old
>> RandomGif list)
>
>
> Yeah, I know. But at least, some of the UI widgets that does not have
> side-effects can be solved. As far as I can see, the discussion here is
> not on this stage yet.
>
> I think something like `mapWithCmd : (a -> Cmd msg) -> Html a -> Html msg`
> would solve it. The problem is that it allows any kind of side effects
> including HTTP. But I don't find good explanation of why HTTP via view is
> bad while random (or time stamp too?) is OK.
>
>
> 2017-04-20 5:40 GMT+09:00 Peter Damoc :
>
>>
>>
>> On Wed, Apr 19, 2017 at 11:19 PM, Yosuke Torii 
>> wrote:
>>
>>> I'm curious what makes it sound that way, since as you noted, that is
 not the point I'm making.

>>>
>>> I don't know if others feels like me or not. But at least for me, "no
>>> components" sounds a bit confusing (it is in official guide too).
>>>
>>
>> I view it as destructive so, you're not alone in seeing something not OK
>> with that.
>>
>>
>>> Also, "no components, no nesting TEA" does not answer the problem
>>> discussed here. So how can we do instead? Maybe introducing sortable-table
>>> pattern is more constructive for this discussion. I think it is a variant
>>> of TEA, managing its own state, but still keeping the form of "reusable
>>> *view*". So great!
>>>
>>
>> the sortable table is a clever component that pushed the external call to
>> update inside the view.
>> You still need what used to be the ChildMsg tag but now instead of
>> calling the Child.update and saving the state it receives the updated
>> state and just saves it.
>>
>> Other than the update trick, it's more or less the same thing as the old
>> MUV triplets.
>> You can even use the pattern to do nesting.
>>
>> The problem is that this approach makes it impossible (as far as I 

[elm-discuss] Re: Scaling Elm

[Marek Fajkus]

Erik,

Marek, about the tea-component package: If you're discouraged by the 
> boilerplate for nested update and view functions, you can clean-up the 
> boilerplate with a single function each... no need to create an entire 
> abstraction package.
>

that sounds like what we do now. First of all that package is at this stage 
just experiment. Anyway I would like to see that kind of abstraction since 
it's both interesting thing to explore and might be useful in practice as 
well.

-- 
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: Comments on the TEA Components package

[Yosuke Torii]

Richard,


> Can you think of a way to use this overloaded word in a way where the
> people in the discussion are not confused by it, even though they think it
> means different things?


I don't know. I just answered the question why I received your message as
"DIY every time". I'm not looking for the alternative for "component" .

I covered how to grow Elm application code bases
> ,
> and Evan covered reuse .
> What is the remaining problem? :)


Again I agree to how to break the monolith and when to do it. But is any of
those reusable things non-TEA? I find UI libraries at packages.elm-lang.com
but they are often written in TEA manner. If it is not simple, how can they
be instead?

Sorry if you have already explained enough. Honestly it is hard to read
whole of messages, as Noah said.


Peter,

The problem is that this approach makes it impossible (as far as I could
> see) to implement the components that need side effects (like the old
> RandomGif list)


Yeah, I know. But at least, some of the UI widgets that does not have
side-effects can be solved. As far as I can see, the discussion here is not
on this stage yet.

I think something like `mapWithCmd : (a -> Cmd msg) -> Html a -> Html msg`
would solve it. The problem is that it allows any kind of side effects
including HTTP. But I don't find good explanation of why HTTP via view is
bad while random (or time stamp too?) is OK.


2017-04-20 5:40 GMT+09:00 Peter Damoc :

>
>
> On Wed, Apr 19, 2017 at 11:19 PM, Yosuke Torii 
> wrote:
>
>> I'm curious what makes it sound that way, since as you noted, that is not
>>> the point I'm making.
>>>
>>
>> I don't know if others feels like me or not. But at least for me, "no
>> components" sounds a bit confusing (it is in official guide too).
>>
>
> I view it as destructive so, you're not alone in seeing something not OK
> with that.
>
>
>> Also, "no components, no nesting TEA" does not answer the problem
>> discussed here. So how can we do instead? Maybe introducing sortable-table
>> pattern is more constructive for this discussion. I think it is a variant
>> of TEA, managing its own state, but still keeping the form of "reusable
>> *view*". So great!
>>
>
> the sortable table is a clever component that pushed the external call to
> update inside the view.
> You still need what used to be the ChildMsg tag but now instead of
> calling the Child.update and saving the state it receives the updated
> state and just saves it.
>
> Other than the update trick, it's more or less the same thing as the old
> MUV triplets.
> You can even use the pattern to do nesting.
>
> The problem is that this approach makes it impossible (as far as I could
> see) to implement the components that need side effects (like the old
> RandomGif list)
>
>
>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/Lo6bG96zotI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Comments on the TEA Components package

[Richard Feldman]

 

> I'm curious what makes it sound that way, since as you noted, that is not 
>>> the point I'm making.
>>>
>>
>> I don't know if others feels like me or not. But at least for me, "no 
>> components" sounds a bit confusing (it is in official guide too). 
>>
>
> I view it as destructive so, you're not alone in seeing something not OK 
> with that. 
>

It's responsible to call out alluring antipatterns that consistently lead 
people to pain.

I'm sorry if you dislike that, but it's important. :)

Other than the update trick, it's more or less the same thing as the old 
> MUV triplets. 
> You can even use the pattern to do nesting.
>

"You literally can do this and it will compile" is not much of a pitch for 
a more complex alternative to the simpler approach that already works well 
.
 
;)

>

-- 
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: Comments on the TEA Components package

[Peter Damoc]

On Wed, Apr 19, 2017 at 11:19 PM, Yosuke Torii  wrote:

> I'm curious what makes it sound that way, since as you noted, that is not
>> the point I'm making.
>>
>
> I don't know if others feels like me or not. But at least for me, "no
> components" sounds a bit confusing (it is in official guide too).
>

I view it as destructive so, you're not alone in seeing something not OK
with that.


> Also, "no components, no nesting TEA" does not answer the problem
> discussed here. So how can we do instead? Maybe introducing sortable-table
> pattern is more constructive for this discussion. I think it is a variant
> of TEA, managing its own state, but still keeping the form of "reusable
> *view*". So great!
>

the sortable table is a clever component that pushed the external call to
update inside the view.
You still need what used to be the ChildMsg tag but now instead of calling
the Child.update and saving the state it receives the updated state and
just saves it.

Other than the update trick, it's more or less the same thing as the old
MUV triplets.
You can even use the pattern to do nesting.

The problem is that this approach makes it impossible (as far as I could
see) to implement the components that need side effects (like the old
RandomGif list)






-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
> I don't know if others feels like me or not. But at least for me, "no 
> components" sounds a bit confusing (it is in official guide too). As you 
> explained the context behind the term "component" is quite huge. I use the 
> word "component" just to say "reusable UI", so "no component" sounds like 
> "no reusable UI". But isn't sortable-table a component? For those who 
> understand the context, it is not a component, but I don't know how others 
> feel (especially who come from JS world).
>

I can see that, but given that the problem is "this word means many 
different things to many different people," the only way to have useful 
discussion seems to be insisting on using less vague terminology. I 
recognize the problem that people are used to using this word [to mean 
different things], but I don't see a better solution.

Can you think of a way to use this overloaded word in a way where the 
people in the discussion are not confused by it, even though they think it 
means different things?

Also, "no components, no nesting TEA" does not answer the problem discussed 
> here. So how can we do instead?
>

I covered how to grow Elm application code bases 
,
 
and Evan covered reuse .

What is the remaining problem? :)

-- 
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: Comments on the TEA Components package

[Yosuke Torii]

>
> I'm curious what makes it sound that way, since as you noted, that is not
> the point I'm making.
>

I don't know if others feels like me or not. But at least for me, "no
components" sounds a bit confusing (it is in official guide too). As you
explained the context behind the term "component" is quite huge. I use the
word "component" just to say "reusable UI", so "no component" sounds like
"no reusable UI". But isn't sortable-table a component? For those who
understand the context, it is not a component, but I don't know how others
feel (especially who come from JS world).

Also, "no components, no nesting TEA" does not answer the problem discussed
here. So how can we do instead? Maybe introducing sortable-table pattern is
more constructive for this discussion. I think it is a variant of TEA,
managing its own state, but still keeping the form of "reusable *view*". So
great!



2017-04-20 4:39 GMT+09:00 Richard Feldman :

> You are right if everyone make their UI from scratch, but how about others
>> who wants to *use *existing library? For instance, date picker is a
>> popular widget. We expect this widget to do lot of complex things behind
>> the scene. But it requires state management (e.g. selected month). Without
>> nested TEA, how can we use this library? [...] elm-sortable-table is a good
>> example (I wonder why nobody mention it, btw). Calling update function is
>> not needed. You can use it just like  element. I hope UI libraries
>> that uses this pattern will increase.
>>
>
> I think Sortable Table is a perfect example of this!
>
> How do we use the library? The same way we use any library: we read the
> docs and plug into the API it provides.
>
> It doesn't need to be any more complicated than that. :)
>
> Terms like "component is proven to be an anti-pattern" sounds too negative
>> for me.
>>
>
> I appreciate the sentiment, but I think it's appropriate to be negative
> when exploring something has yielded an overall negative result. :)
>
>
>> It sounds like "Elm proposes DIY every time, no reusable UI ever!", even
>> if you mean "no need to make everything a component for building app, there
>> are actually not so many reusable UI parts in practice".
>>
>
> I'm curious what makes it sound that way, since as you noted, that is not
> the point I'm making.
>
> Any feedback on how I could be clearer would be appreciated!
>
>> --
> 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/Lo6bG96zotI/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: Scaling Elm

[Erik Lott]

Marek, about the tea-component package: If you're discouraged by the 
boilerplate for nested update and view functions, you can clean-up the 
boilerplate with a single function each... no need to create an entire 
abstraction package.

On Wednesday, April 19, 2017 at 3:34:31 PM UTC-4, Marek Fajkus wrote:
>
> Marek,
>>
>> One difference might be that we don't deal with sign-in in SPA itself. 
>>> We're using Html.programWithFlags and passing user info to elm on 
>>> embedding. 
>>
>>
>> Good stuff. Less work when you don't have to worry about auth states.
>>
>
> it's helping us a lot. Anyway this architecture is used even in js app and 
> predates me joining project. Whole login happens on different domain with 
> different service. Anyway it also means we have to do one XHR request 
> before starting app.
>
> this is example of idea I'm experimenting with: 
> https://github.com/turboMaCk/elm-app-composition-example
> that led to: https://github.com/turboMaCk/tea-component
>
> we're not using exactly that right now. Also package itself is removed 
> from package.elm-lang.org. It will be republished once I manage to change 
> name + docs and I don't really enjoy doing that so I'm taking my time:D
>

-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
> You are right if everyone make their UI from scratch, but how about others 
> who wants to *use *existing library? For instance, date picker is a 
> popular widget. We expect this widget to do lot of complex things behind 
> the scene. But it requires state management (e.g. selected month). Without 
> nested TEA, how can we use this library? [...] elm-sortable-table is a good 
> example (I wonder why nobody mention it, btw). Calling update function is 
> not needed. You can use it just like  element. I hope UI libraries 
> that uses this pattern will increase.
>

I think Sortable Table is a perfect example of this!

How do we use the library? The same way we use any library: we read the 
docs and plug into the API it provides.

It doesn't need to be any more complicated than that. :)

Terms like "component is proven to be an anti-pattern" sounds too negative 
> for me.
>

I appreciate the sentiment, but I think it's appropriate to be negative 
when exploring something has yielded an overall negative result. :)
 

> It sounds like "Elm proposes DIY every time, no reusable UI ever!", even 
> if you mean "no need to make everything a component for building app, there 
> are actually not so many reusable UI parts in practice".
>

I'm curious what makes it sound that way, since as you noted, that is not 
the point I'm making.

Any feedback on how I could be clearer would be appreciated!

>

-- 
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: Scaling Elm

[Marek Fajkus]

>
> Marek,
>
> One difference might be that we don't deal with sign-in in SPA itself. 
>> We're using Html.programWithFlags and passing user info to elm on 
>> embedding. 
>
>
> Good stuff. Less work when you don't have to worry about auth states.
>

it's helping us a lot. Anyway this architecture is used even in js app and 
predates me joining project. Whole login happens on different domain with 
different service. Anyway it also means we have to do one XHR request 
before starting app.

this is example of idea I'm experimenting 
with: https://github.com/turboMaCk/elm-app-composition-example
that led to: https://github.com/turboMaCk/tea-component

we're not using exactly that right now. Also package itself is removed from 
package.elm-lang.org. It will be republished once I manage to change name + 
docs and I don't really enjoy doing that so I'm taking my time:D

-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
> I've seen agile teams that could generate lots of small changes but when 
> faced with needing to do something big found themselves profoundly stuck.
>

In Elm?

the distillation of the don't use nested TEA argument when people have 
> asked what to do instead has tended to be "use functions" which as I've 
> noted doesn't mean much in a functional language.
>

It means YAGNI . Don't 
overengineer it. :)

As for C++ example I cited, there is nothing Elm is bringing to the table 
> that makes it superior to C++ in the case I described. C++ is fully 
> type-checked.
>

In Elm, if I refactor something, my typical experience is "once it 
compiles, it works." It's been a long time since I did C++, but my memory 
of that experience was a far cry from that.

It sounds like your C++ refactoring experience has been close to your Elm 
refactoring experience, which surprises me.

-- 
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: Comments on the TEA Components package

[Noah Hall]

Hey folks,

I just want to say, it's really really really hard to reply to these
posts which are both really long and really dense. It's better to
answer in a terse, short format. This is a conversation - not a blog
post. Longer comments and responses are usually better in a blog post,
because it's quite hard to keep all the context in our heads for each
mail on a mailing list.

Regarding how to structure code for large apps, I really recommend
looking at the NRI elm-style-guide.
https://github.com/noredink/elm-style-guide#nri

The "reusable" parts are those prefixed by `Nri`. Here's an example of
what some type signatures might look like:

-- Button.elm
view : msg -> Html msg
view onClick = ...

-- Emoji.elm
type Emoji = Smile | SadFace
view : Emoji -> Html msg
view emoji = ...

-- Leaderboard.elm

type LeaderSettings field = { numberOfPlayers : Int, fields: List field }
view : LeaderSettings field -> (field -> msg) -> Html msg
view settings onFieldChange = ...


I recommend trying out this approach, and see how you like it. It
makes implementing things _so_ simple. I've tried every approach under
the sun, and seen more codebases than I can count. This is the one
that wins for me.

If anyone tries this approach, but fails to get their head around how
to refactor their code to work with it, or fails to see how it's
simpler, hit me up on Slack (eeue56) or at elm-europe or
https://osloelmday.no, and I will guarantee your code will walk away
looking nicer than it did before.

On Wed, Apr 19, 2017 at 8:50 PM, Mark Hamburg  wrote:
> The monster model design is one aspect that leads to the ball of mud code.
> Let's look at the source quote for the term big ball of mud:
>
> A Big Ball of Mud is a haphazardly structured, sprawling, sloppy,
> duct-tape-and-baling-wire, spaghetti-code jungle. These systems show
> unmistakable signs of unregulated growth, and repeated, expedient repair.
> Information is shared promiscuously among distant elements of the system,
> often to the point where nearly all the important information becomes global
> or duplicated. The overall structure of the system may never have been well
> defined. If it was, it may have eroded beyond recognition. Programmers with
> a shred of architectural sensibility shun these quagmires. Only those who
> are unconcerned about architecture, and, perhaps, are comfortable with the
> inertia of the day-to-day chore of patching the holes in these failing
> dikes, are content to work on such systems.
>
> — Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on
> Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois,
> September 1997
>
> When everything starts out in one place with access to everything else, it's
> natural to end up with everything talking to and depending on everything
> else — or at least the dependencies are less likely to be well regulated
> because there is no mechanism doing the regulation. Now, as conservative
> politicians will love to tell you, regulations get in the way and we can be
> more productive without them, so yes, this unregulated environment is
> seemingly more productive. The type system will help in detecting out and
> out errors in making changes but once things get intertwined, they become
> less amenable to significant change. That's often fine for an agile
> development model in which one focuses on small changes but I've seen agile
> teams that could generate lots of small changes but when faced with needing
> to do something big found themselves profoundly stuck. An approach which
> basically seems to advocate building a monolithic, intertwined codebase and
> if that gets to be too much, here are some techniques to break it down after
> the fact will work to an extent but will be fighting to apply order to chaos
> and almost all the time it will be easier for a developer trying to get a
> task done to just add a little more chaos.
>
> As for your specific advice, it includes several useful points and I've
> refactored code using those same techniques, but the distillation of the
> don't use nested TEA argument when people have asked what to do instead has
> tended to be "use functions" which as I've noted doesn't mean much in a
> functional language. (I guess it means use functions rather than types but
> since types are what allow us to make illegal states impossible, I don't
> think it really comes down to just use functions either.) What TEA and
> nested TEA provided was architectural guidance on how to structure things
> for long term evolution. Saying, if your update function gets too big you
> can handle individual cases with separate functions is I guess useful advice
> but something that I would hope would be obvious to most people working in a
> functional language. What sort of calling conventions work well? Which ones
> don't work well and should be avoided? That's the sort of architectural
> advice that can be put into practice early on and 

Re: [elm-discuss] Re: Comments on the TEA Components package

[Mark Hamburg]

The monster model design is one aspect that leads to the ball of mud code.
Let's look at the source quote for the term big ball of mud:

A Big Ball of Mud is a haphazardly structured, sprawling, sloppy,
duct-tape-and-baling-wire, spaghetti-code
 jungle. These systems show
unmistakable signs of unregulated growth, and repeated, expedient repair.
Information is shared promiscuously among distant elements of the system,
often to the point where nearly all the important information becomes
global or duplicated. The overall structure of the system may never have
been well defined. If it was, it may have eroded beyond recognition.
Programmers with a shred of architectural sensibility shun these quagmires.
Only those who are unconcerned about architecture, and, perhaps, are
comfortable with the inertia of the day-to-day chore of patching the holes
in these failing dikes, are content to work on such systems.
— Brian Foote and Joseph Yoder, *Big Ball of Mud.* Fourth Conference on
Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello,
Illinois, September 1997

When everything starts out in one place with access to everything else,
it's natural to end up with everything talking to and depending on
everything else — or at least the dependencies are less likely to be well
regulated because there is no mechanism doing the regulation. Now, as
conservative politicians will love to tell you, regulations get in the way
and we can be more productive without them, so yes, this unregulated
environment is seemingly more productive. The type system will help in
detecting out and out errors in making changes but once things get
intertwined, they become less amenable to significant change. That's often
fine for an agile development model in which one focuses on small changes
but I've seen agile teams that could generate lots of small changes but
when faced with needing to do something big found themselves profoundly
stuck. An approach which basically seems to advocate building a monolithic,
intertwined codebase and if that gets to be too much, here are some
techniques to break it down after the fact will work to an extent but will
be fighting to apply order to chaos and almost all the time it will be
easier for a developer trying to get a task done to just add a little more
chaos.

As for your specific advice, it includes several useful points and I've
refactored code using those same techniques, but the distillation of the
don't use nested TEA argument when people have asked what to do instead has
tended to be "use functions" which as I've noted doesn't mean much in a
functional language. (I guess it means use functions rather than types but
since types are what allow us to make illegal states impossible, I don't
think it really comes down to just use functions either.) What TEA and
nested TEA provided was architectural guidance on how to structure things
for long term evolution. Saying, if your update function gets too big you
can handle individual cases with separate functions is I guess useful
advice but something that I would hope would be obvious to most people
working in a functional language. What sort of calling conventions work
well? Which ones don't work well and should be avoided? That's the sort of
architectural advice that can be put into practice early on and expect it
to pay off later when changes need to be made. For example, to buttress the
non-component view of the world, one could push on the fact that many views
do not need to own their own state but can simply be functions that render
state provided from somewhere else. One could phrase that as: "You have a
view function but ask yourself whether you really need a model and an
update or whether those are better handled somewhere else. If you do so,
then you can take a big pile of view code and move it somewhere else and
not need to look at it when trying to figure out what is going on in your
model."

As for C++ example I cited, there is nothing Elm is bringing to the table
that makes it superior to C++ in the case I described. C++ is fully
type-checked. Mutability v immutability was not a concern here. Of concern
was that question "which parts of this are visible to other code for the
benefit of code within the would be library and which parts are visible
because they are expected to be stable interfaces for other code". And the
fact it was a question arose exactly because the code base started as an
entity that only needed to serve itself and for which the refactorings were
all just adjustments within those bounds. The choices were expedient for
immediate development but detrimental to long-term reuse.

Should one build everything to be reusable/replaceable? Almost certainly
not because doing so does come with overhead. But identifying likely break
points where code may need to be either reused or replaced and structure
those break points up front to enable that reduces the effort when you do
need it 

Re: [elm-discuss] Re: Comments on the TEA Components package

[Yosuke Torii]

Richard,

I'm curious how your product *uses* (not makes) external UI library. You 
are right if everyone make their UI from scratch, but how about others who 
wants to *use *existing library? For instance, date picker is a popular 
widget. We expect this widget to do lot of complex things behind the scene. 
But it requires state management (e.g. selected month). Without nested TEA, 
how can we use this library? I think TEA gives the best user experience for 
those widgets.

If I understand correctly, Marek's library is trying to reduce the cost of 
using them. I agree with your opinion about breaking the monolith or "don't 
make needless things for saving time". It's the best practice of agile 
development. But does "scale" mean just "my app become big"? I expect that 
word to mean "easy to use external library, custom widgets can be easily 
made and they can be used across pages".

I don't think the exploration of TEA is finished. elm-sortable-table is a 
good example (I wonder why nobody mention it, btw). Calling update function 
is not needed. You can use it just like  element. I hope UI 
libraries that uses this pattern will increase.

Terms like "component is proven to be an anti-pattern" sounds too negative 
for me. It sounds like "Elm proposes DIY every time, no reusable UI ever!", 
even if you mean "no need to make everything a component for building app, 
there are actually not so many reusable UI parts in practice".



2017年4月20日木曜日 2時27分09秒 UTC+9 Richard Feldman:
>
> so, the Model-View-Update triplet *is NOT* the wrong unit of composition 
>> for Elm applications? :) 
>>
>> > How do you propose to split the functionality one has in a highly 
>>> complex app with a lot of pages without using those triplets?
>>>
>>> I don't haha...I just defended their use a few posts ago, complete with 
>>> the specific example of the reusable signup form.
>>
>>
> To recap:
>
>1. Earlier 
> 
>I said "between 0.16 and today, *we learned that a Model-View-Update 
>triplet is the wrong unit of composition for Elm applications...composing 
>individual functions* was both simpler and consistently led to a much 
>better experience. I've laid out my advice for specifically how to do that 
>here 
>
> 
>."
>2. Later 
> 
>I pointed out an example of when it would be useful to use Html.map 
>and Cmd.map to make a reusable signup form, and for that use case it 
>happened to make sense to have a separate model, view, and update.
>
> In (1) I am saying that I expect you'll have a better time if you think 
> about building Elm applications in terms of *composing individual 
> functions*, not in terms of composing Model/View/Update triplets.
>
> In (2) I am giving an example of a very specific set of circumstances in 
> which a separate Model/View/Update makes sense.
>
> In summary: "Here is a useful but complex tool. Always reach for a simpler 
> one first." 
>
>>

-- 
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: Scaling Elm

[Erik Lott]

Marek,

One difference might be that we don't deal with sign-in in SPA itself. 
> We're using Html.programWithFlags and passing user info to elm on 
> embedding. 


Good stuff. Less work when you don't have to worry about auth states.


On Wednesday, April 19, 2017 at 1:48:39 PM UTC-4, Marek Fajkus wrote:
>
> That appears to have much in common with our app. It seems useful to 
>> compare what people building SPAs are currently doing so here's a rough 
>> gist of the folder/file structure that we're using 
>> https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec. There's a 
>> few differences worth pulling out
>>
>> 1) We have the Store abstraction that I mentioned for data synchronisation
>> 2) We have two different top level modules depending on whether or not 
>> you're logged in (AppState)
>> 3) We split our larger pages into sections which function as separate 
>> mini apps 
>>
>> I've found myself thinking in terms of mini apps a lot lately. Each Page 
>> and each page Section functions as a separate mini app, notably they don't 
>> interact with each other, the only communication between them is via data 
>> in the Store which they all share.
>>
>
> We're using similar approach and are happy as well. One difference might 
> be that we don't deal with sign-in in SPA itself. We're using 
> Html.programWithFlags and passing user info to elm on embedding. Some more 
> info here https://groups.google.com/forum/#!topic/elm-dev/iqErmKHnLDY and 
> here https://groups.google.com/forum/#!topic/elm-discuss/Lo6bG96zotI
>
>

-- 
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: Scaling Elm

[Erik Lott]

Oliver,

We have the Store abstraction that I mentioned for data synchronisation


Sure. I'm sure this isn't too different - conceptually - from what we're 
doing. Although our app manages some complicated processes, the 
communication with the backend server is as simple as it gets - json gets 
and posts.

>
> We have two different top level modules depending on whether or not you're 
> logged in (AppState)


It's interesting that you mention that, because we also experimented with 
separating our Auth and Public sides of the app via the type system. I 
can't remember why we chose to flatten the app instead... but we did. 

We split our larger pages into sections which function as separate mini 
> apps 


Yeah, we do the same when necessary, although we use different naming. A 
"Page" in our applications always represent a single onscreen page - so 
routes and pages are always mapped one to one. When we have multiple 
components/widgets on a page, those are broken into separate modules 
(mini-apps as you say) and likely stored in the components/widget folder, 
or broken out into a standalone package. 

I've found myself thinking in terms of mini apps a lot lately. Each Page 
> and each page Section functions as a separate mini app, notably they don't 
> interact with each other, the only communication between them is via data 
> in the Store which they all share.


Exactly. 


On Wednesday, April 19, 2017 at 12:52:11 PM UTC-4, Oliver Searle-Barnes 
wrote:
>
> That appears to have much in common with our app. It seems useful to 
> compare what people building SPAs are currently doing so here's a rough 
> gist of the folder/file structure that we're using 
> https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec. There's a 
> few differences worth pulling out
>
> 1) We have the Store abstraction that I mentioned for data synchronisation
> 2) We have two different top level modules depending on whether or not 
> you're logged in (AppState)
> 3) We split our larger pages into sections which function as separate mini 
> apps 
>
> I've found myself thinking in terms of mini apps a lot lately. Each Page 
> and each page Section functions as a separate mini app, notably they don't 
> interact with each other, the only communication between them is via data 
> in the Store which they all share.
>
>
>
> On Wednesday, 19 April 2017 17:57:28 UTC+2, Erik Lott wrote:
>>
>> I'm a little pressed for time, but I'll try to give a general 
>> architecture outline that works really well for us. Our primary elm SPA is 
>> a customer facing administrative control panel that communicates with a 
>> backend api server and amazon S3. The app manages authentication, 
>> authorization, subscription status, and currently has 17 'pages'. This 
>> particular app is a Static SPA (currently served from s3-cloudfront combo).
>>
>> *Backend API Client*
>> We have an api client written in elm that resides with the api server. 
>> The api-client elm module can be pulled into any elm project that needs to 
>> communicate with the backend server, and includes all http requests, model 
>> types, model json decoders, and any necessary model helpers. Importantly, 
>> this is where authorization and authentication is handled as well. A user 
>> who successfully signs-in via the api will be granted an authorization 
>> token. The authorization token must be provided with each following request 
>> to the api. 
>>
>> example: 
>> https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c
>>
>> *SPA*
>> The folder structure for the majority of our elm SPA's end up as follows:
>>   - Component (folder)
>>   - Pages (folder)
>>   - Main.elm
>>   - Route.elm
>>   - Routing.elm
>>   .. any other app/infrastructure related modules
>>
>> *Route.elm*
>> Module encapsulating functions relating to routes:
>>
>> https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-route-elm
>>
>> *Routing.elm*
>> The routing module holds the state of the current page, and isolates 
>> logic pertaining to which page is displayed for each route
>>
>> https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-routing-elm
>>
>> *Main.elm*
>> This is where the top level modules are wired together. It's difficult to 
>> create a generate example for this since your Main.elm will be application 
>> specific. Here is a hacked together example of a Main that you can sift 
>> through and try to understand what's going on in this specific application:
>>
>> https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-main-elm
>>
>> Some things to note: The client configuration is stored in the main model 
>> and passed down into the pages. When a page triggers a logout or login, 
>> that fact must travel back up to the main module so the client 
>> configuration state can be adjusted accordingly. If you need to know how to 
>> do this, I'm happy to explain.
>>
>> *Pages*
>> Here is an example page:
>>
>> 

Re: [elm-discuss] Re: Task ports: A proposal to make it easier to integrate JS with Elm.

[Mark Hamburg]

Since the call is for concrete use cases, here is one: Reading from local
storage.

My program wants to cache various things in local storage or for the
purposes of this example it wants to read from various locations in local
storage to get the values needed at various points in the model/UX. If we
didn't use local storage and just used HTTP, we would generate HTTP
requests at the points where we needed the information and using Elm
message routing get the results delivered back. We would like to do the
same thing with local storage as a cache — possibly followed by an HTTP
fallback if we found nothing in local storage but that's beyond the scope
here.

The analogous API to the HTTP case would be something like:

get : (Result Error Json.Decode.Value -> msg) -> String -> Cmd msg


Or to make it more composable — cough, tasks v commands, cough — we might
have:

getTask : String -> Task Error Json.Decode.Value


Given that the Elm local storage effects manager seems to be on indefinite
hold, we need to use ports. So, what does it take to do this using ports?

Command ports don't return results. Subscription ports don't convey
information to the JavaScript side. So, we have to use a pair of them. A
command to trigger work on the JavaScript side and a subscription to
receive values back. But how do we match results coming back with requests
coming in? How do we tag those results appropriately for delivery?

There would seem to be two options:

1. For every request we need to make, create a separate pair of ports. Now,
we don't need to pass in the key string because the key is built into the
port identity. In fact, it would be bad to pass in the key string since
that would reintroduce the question of which response goes with which
request. This approach will work if we can statically enumerate ahead of
time all of the keys we are interested in AND we are prepared to write
JavaScript handler code for each and every request. This might be viable
for the big flat applications that some people like to advocate but it's a
pretty messy maintenance situation and it breaks the moment we can't
statically enumerate the keys of interest.

2. When we send a request in, we tag it with an identifying number and
maintain a dictionary mapping those id's to tagger functions. The
JavaScript side includes the id in its response — basically the same thing
Phoenix push messages do — and the subscription port feeds into logic that
looks up the id and tags and delivers the result. Those of you who are
horrified at the thought of storing functions in the model should perhaps
stop right here because that id to tagger function dictionary is doing
exactly that. But even if one gets beyond that, note that this approach
won't work just like HTTP because we will need at some point before this
becomes a command to update the delivery map. That can either happen by
replacing commands with requests or by allowing arbitrary update code to
touch the shared global id generator and delivery map. Neither approach is
as straightforward as the HTTP case.

This could be addressed by extending command ports to allow them to return
responses but if we're doing that, why not just make them composable and
generate tasks that take a Json.Encode.Value as input and return a Task
PortError Json.Decode.Value (where PortError might just be another
Json.Decode.Value or it might be some other response structure that could
reflect other implementation errors TBD):

port get : Json.Encode.Value -> Task Task.PortError Json.Decode.Value


Now, I can wrap this up in code to do the encoding of strings to JSON
(trivial) and map the resulting task result to do any appropriate decoding
and delivery.

One could argue that this would all be handled in the local storage effect
manager thereby rendering this example moot. But as noted above, that
effects manager seems to be on indefinite hold. Furthermore, local storage
was just a convenient and simple example. The exact same arguments could
apply to almost any storage mechanism we wanted to talk to. If the Elm
community were cranking out effects managers to handle these cases that
would clearly mitigate this issue but that hasn't been happening. What's
more such effects managers would almost certainly end up writing kernel
(née native) code to provide task support for the interaction with
JavaScript so instead of having a single mechanism for marshaling these
interactions and keeping the relevant code out of the kernel, we would
 instead have a growing number of pieces of code wanting kernel rights.

Mark

On Fri, Apr 14, 2017 at 11:39 AM, Simon  wrote:

> +1 for Task ports.
>
> On Friday, 14 April 2017 20:32:24 UTC+2, Nicholas Hollon wrote:
>>
>> The process:
>>
>> 1. Share your ideas, experience, & code on elm-discuss.
>> 2. Accept that you have no direct influence over what Evan works on next.
>> 3. Look at the release history  for Elm.
>> Notice that changes happen slowly. 

Re: [elm-discuss] Re: Comments on the TEA Components package

[Richard Feldman]

>
> "just write one monster model" approach
>

Mark, this is about the third time you've insinuated that my explanation of 
how to split things up 

 somehow 
amounts to not splitting things up at all. Someone called you out on it 
, and 
then you switched insults from "ball of mud" to "monster model." If you 
genuinely want to have a discussion, it's important not to misrepresent the 
other side.

It's also weird to me that you keep responding to my point of "this 
approach has worked really well for lots of Elm programmers, in practice, 
in real life, already" with "I bet that won't work well in practice, in 
real life, based on my experiences in other languages." We're past the 
point of theoretical predictions here. The experiment has already been 
done, and then replicated successfully many times.

Your comment that "this approach didn't work for us in C++" seems 
particularly weird. I'd say there are "a few" differences between Elm and 
C++, refactoring experience included. ;)

-- 
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: Scaling Elm

[Eric G]

I think this would be great to have and would be glad to contribute. 

Just to be clear, you are proposing we come up with one set of 
functionality, that then multiple people implement using different 
approaches? Like TodoMVC, but a larger example that also encompasses server 
communication and build management?

I think the scope has to be really narrow and well-defined, and the domain 
pretty familiar to people already, for this to work.  

I agree with Marek that it needs some aspect of updating remote data. Re. 
MusicBrainz idea, perhaps something like a bookmarking or "my favorites" 
feature.  Also, to simplify, perhaps there should be a 'reference server 
app' so that people don't have to implement that as well as the client 
side. I don't think we should assume 'serverless', i.e. client app talks 
directly to the service.

Personally, I would like to see an example based around a multi-user app -- 
i.e., where multiple users collaborate on editing the same entities (not 
necessarily in real time). For example, a UI that models a simple workflow 
like *Alice creates a document that Bob can edit and then that Carla either 
can approve or send back to Alice and Bob to make further edits.* Maybe 
some example can be built around MusicBrainz that involves collaboration so 
the domain is not quite so boring :)

My point is, TodoMVC and many other such examples are apps where each users 
owns his or her own data and there is no collaboration, and a minimal state 
machine. The weakness of these examples is they are utterly unlike most 
business applications. That's also their strength -- they are relatively 
easy to implement and compare :)   


On Wednesday, April 19, 2017 at 11:21:04 AM UTC-4, Marek Fajkus wrote:
>
> I would like to help with this by contributing some version.
>
> Anyway it's crucial to point out that this is really not easy thing to do. 
> I like idea with MusicBrainz db but that doesn't include changing data on 
> server. Also it's hard to demonstrate scaling without some noise (unrelated 
> business logic) and the same time do not introduce over-engineering at the 
> process anyone can use against whole idea. At least for me it's hard to 
> imagine scope of this. I also believe this is the reason we there isn't 
> something like this yet.
>
> Honestly ultimate solution would be to start some actually useful OSS 
> project which and solve some real use case. By that I mean something 
> bigger. @Oliver mentioned he has Ember background. In ember there is 
> Discourse and Hospital Run for instance.
> Anyway now I feel I'm asking for too much and have doubts I'll be able to 
> contribute for project like this... sadly... It is just idea that come to 
> my mind.
>
> On Wednesday, April 19, 2017 at 11:11:05 AM UTC+2, Peter Damoc wrote:
>>
>> Hello community, 
>>
>> Scaling Elm apps seams to be a recurring topic. 
>>
>> I was wondering if maybe we could negotiate a minimal set of 
>> functionality, something similar to ToDoMVC, that could be implemented 
>> using different approaches to explore what could be the best way to 
>> structure the code. 
>>
>> What should this minimal example cover and what this minimal example 
>> should be (topic)?
>>
>> I'll start the list with some bits of functionality that I would like: 
>>
>> - multiple pages with common structure (sidebar/navbar)
>> - navigation without reloading the app (SPA routing without the hash) 
>> - authentication 
>> - complex widget reuse (a module/widget that generates side-effects; e.g. 
>> a weather widget, some stock ticker, an ad provided by a third party)
>> - styling (CSS)
>>
>> I would also like the example to cover real world concerns of: 
>> - using a build manager to integrate with other technologies 
>> - development mode - deployment build
>> - testing 
>>
>> As for topic, I was thinking about an interface to the MusicBrainz 
>> Database (a simplified interface).
>>
>> What do you think? 
>> What bits of functionality would you like to see exemplified? 
>> Are you aware of any other project (in other languages) that exemplifies 
>> a minimal set of functionality and could be used as a template?  
>>
>>
>> -- 
>> 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.

[elm-discuss] Re: Scaling Elm

[Marek Fajkus]

>
> That appears to have much in common with our app. It seems useful to 
> compare what people building SPAs are currently doing so here's a rough 
> gist of the folder/file structure that we're using 
> https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec. There's a 
> few differences worth pulling out
>
> 1) We have the Store abstraction that I mentioned for data synchronisation
> 2) We have two different top level modules depending on whether or not 
> you're logged in (AppState)
> 3) We split our larger pages into sections which function as separate mini 
> apps 
>
> I've found myself thinking in terms of mini apps a lot lately. Each Page 
> and each page Section functions as a separate mini app, notably they don't 
> interact with each other, the only communication between them is via data 
> in the Store which they all share.
>

We're using similar approach and are happy as well. One difference might be 
that we don't deal with sign-in in SPA itself. We're using 
Html.programWithFlags and passing user info to elm on embedding. Some more 
info here https://groups.google.com/forum/#!topic/elm-dev/iqErmKHnLDY and 
here https://groups.google.com/forum/#!topic/elm-discuss/Lo6bG96zotI

-- 
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: Comments on the TEA Components package

[Richard Feldman]

>
> so, the Model-View-Update triplet *is NOT* the wrong unit of composition 
> for Elm applications? :) 
>
> > How do you propose to split the functionality one has in a highly 
>> complex app with a lot of pages without using those triplets?
>>
>> I don't haha...I just defended their use a few posts ago, complete with 
>> the specific example of the reusable signup form.
>
>
To recap:

   1. Earlier 
    I 
   said "between 0.16 and today, *we learned that a Model-View-Update 
   triplet is the wrong unit of composition for Elm applications...composing 
   individual functions* was both simpler and consistently led to a much 
   better experience. I've laid out my advice for specifically how to do that 
   here 
   

   ."
   2. Later 
    I 
   pointed out an example of when it would be useful to use Html.map and 
   Cmd.map to make a reusable signup form, and for that use case it 
   happened to make sense to have a separate model, view, and update.

In (1) I am saying that I expect you'll have a better time if you think 
about building Elm applications in terms of *composing individual functions*, 
not in terms of composing Model/View/Update triplets.

In (2) I am giving an example of a very specific set of circumstances in 
which a separate Model/View/Update makes sense.

In summary: "Here is a useful but complex tool. Always reach for a simpler 
one first." 

>

-- 
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: Scaling Elm

[Oliver Searle-Barnes]

That appears to have much in common with our app. It seems useful to 
compare what people building SPAs are currently doing so here's a rough 
gist of the folder/file structure that we're 
using https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec. 
There's a few differences worth pulling out

1) We have the Store abstraction that I mentioned for data synchronisation
2) We have two different top level modules depending on whether or not 
you're logged in (AppState)
3) We split our larger pages into sections which function as separate mini 
apps 

I've found myself thinking in terms of mini apps a lot lately. Each Page 
and each page Section functions as a separate mini app, notably they don't 
interact with each other, the only communication between them is via data 
in the Store which they all share.



On Wednesday, 19 April 2017 17:57:28 UTC+2, Erik Lott wrote:
>
> I'm a little pressed for time, but I'll try to give a general architecture 
> outline that works really well for us. Our primary elm SPA is a customer 
> facing administrative control panel that communicates with a backend api 
> server and amazon S3. The app manages authentication, authorization, 
> subscription status, and currently has 17 'pages'. This particular app is a 
> Static SPA (currently served from s3-cloudfront combo).
>
> *Backend API Client*
> We have an api client written in elm that resides with the api server. The 
> api-client elm module can be pulled into any elm project that needs to 
> communicate with the backend server, and includes all http requests, model 
> types, model json decoders, and any necessary model helpers. Importantly, 
> this is where authorization and authentication is handled as well. A user 
> who successfully signs-in via the api will be granted an authorization 
> token. The authorization token must be provided with each following request 
> to the api. 
>
> example: https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c
>
> *SPA*
> The folder structure for the majority of our elm SPA's end up as follows:
>   - Component (folder)
>   - Pages (folder)
>   - Main.elm
>   - Route.elm
>   - Routing.elm
>   .. any other app/infrastructure related modules
>
> *Route.elm*
> Module encapsulating functions relating to routes:
>
> https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-route-elm
>
> *Routing.elm*
> The routing module holds the state of the current page, and isolates logic 
> pertaining to which page is displayed for each route
>
> https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-routing-elm
>
> *Main.elm*
> This is where the top level modules are wired together. It's difficult to 
> create a generate example for this since your Main.elm will be application 
> specific. Here is a hacked together example of a Main that you can sift 
> through and try to understand what's going on in this specific application:
>
> https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-main-elm
>
> Some things to note: The client configuration is stored in the main model 
> and passed down into the pages. When a page triggers a logout or login, 
> that fact must travel back up to the main module so the client 
> configuration state can be adjusted accordingly. If you need to know how to 
> do this, I'm happy to explain.
>
> *Pages*
> Here is an example page:
>
> https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-page-apples-elm
>
> *Components* 
> There are mostly shared headers, footers,menus, that are shared across 
> various pages. Some have their own state, but most are simple reusable view 
> helpers. 
>
> Sorry for being short on descriptions. Hopefully the examples are enough 
> to give you a sense of direction and organization. Happy to answer any 
> questions.
>
> On Wednesday, April 19, 2017 at 5:11:05 AM UTC-4, Peter Damoc wrote:
>>
>> Hello community, 
>>
>> Scaling Elm apps seams to be a recurring topic. 
>>
>> I was wondering if maybe we could negotiate a minimal set of 
>> functionality, something similar to ToDoMVC, that could be implemented 
>> using different approaches to explore what could be the best way to 
>> structure the code. 
>>
>> What should this minimal example cover and what this minimal example 
>> should be (topic)?
>>
>> I'll start the list with some bits of functionality that I would like: 
>>
>> - multiple pages with common structure (sidebar/navbar)
>> - navigation without reloading the app (SPA routing without the hash) 
>> - authentication 
>> - complex widget reuse (a module/widget that generates side-effects; e.g. 
>> a weather widget, some stock ticker, an ad provided by a third party)
>> - styling (CSS)
>>
>> I would also like the example to cover real world concerns of: 
>> - using a build manager to integrate with other technologies 
>> - development mode - deployment build
>> - testing 
>>
>> As for topic, I was thinking about an interface to the MusicBrainz 
>> Database (a 

Re: [elm-discuss] Re: Comments on the TEA Components package

[Mark Hamburg]

Here is where our app is migrating after starting as an intermixture of
view-side code and data-side code.

The high level split is a store and a display. The store knows about things
like how to talk to our server. As I summarized it, the UX code should know
nothing about Phoenix. The display manages the user interaction. Both sides
have state. The store, well, stores information — generally a reflection of
what is on the server or should be on the server. The display, however,
also stores information like whether panels are open, the state of
animations, etc. Just as knowledge of Phoenix doesn't belong in the UX,
knowledge of animations does not belong in the store.

This isn't a radical design by any means. A lot of code is built this way.
It's perhaps more interesting to this discussion to observe that the Elm
community doesn't encourage even this sort of factoring and in fact naive
use of MUV/TEA does lead to a deep intermingling of store and display
concerns. (I guess the "just write one monster model" approach deals with
this by saying that code can choose to only interact with parts of the
model.)

What I've been working through while engineering this split is how to
manage coordination between the two sides.

Sending messages from the display to the store is pretty simple. We've
replaced commands in the update signature with a list of "out messages".
These messages include internal notifications — e.g., canceled, finished,
please shift the target somewhere else, etc — and operations for the world
beyond the display which includes commands to flow out the top of the app,
requests for work by the store, and requests for random number generation
using a shared generator. (This last is much like the effects manager
random logic but it uses the Pcg generator.) The operations are all subject
to command style mapping to adjust the tagging for their responses back to
the display. Notifications are just notifications. The current
implementation involves more boilerplate at every nesting within the
display than I would really like but I'm working on that.

Getting data from the store to the display is more interesting and is an
area I continue to work through.

One naive approach we looked at would be to just hand the store into the
view functions and let them query the store as needed to do their work.
There are two problems with this.

The first is that some display side concepts such as which item is
currently targeted/selected — it's a display-side concept since the server
should never know — need to update in response to store-side changes. For
example, if the selected item goes away, we may want to automatically
select something else. Since we can't do updates during view calls, we need
to provide a way for the display to react to store changes. Our solution
here has been to treat this as one would treat the data if it were entirely
stored on the server: we store a local copy on the display side and perform
a fetch operation to get it from the store. This means that the display
gets to validate its copy and the problem of keeping that copy up to date
is exactly the same as the problem one would have if there were no store
and we were just talking over the wire to a server.(*)

This leads to the second problem: A fetch operation is great for getting
the initial information and replacing commands with operations makes that
pretty easy to implement but how do we keep the data up to date and
relatedly how do we keep track of when the display side loses interest?
Here I'm looking at building a subscription equivalent (an observation?)
but I'm not wild about what it would take to make it efficient in the
presence of say scrolling a grid of several thousand items starting and
stopping observations as the visible items change. But efficiency with
large sets of subscriptions seems like something the Elm implementation
hasn't really worried about either since I think it regenerates and
collects up subscriptions after every mutation — if you adhere to the "no
functions in the model" advice(**), you can't cache your subscriptions
because they hold tagger functions — and has the effects managers diff the
new subscriptions against the old. Maybe things are just efficient enough
as it is but I suspect that it's more likely that with so few effects
managers for Elm, few applications generate large number of subscriptions
at any one time. But lacking any better ideas, we will probably start with
mirroring subscriptions and see whether it blows up the time complexity in
a noticeable way.

Moving on, there's one other bit of code structuring that we've only
recently adopted but which has clarified a lot of code and should help with
writing unit tests. The display side models for the overall experience or
pieces of the experience or particular modal portions of the experience
(e.g, sign in) tend to have a model that hold display specific information
like the state of panels or animations and a logic submodel that holds 

[elm-discuss] Re: Scaling Elm

[Erik Lott]

I'm a little pressed for time, but I'll try to give a general architecture 
outline that works really well for us. Our primary elm SPA is a customer 
facing administrative control panel that communicates with a backend api 
server and amazon S3. The app manages authentication, authorization, 
subscription status, and currently has 17 'pages'. This particular app is a 
Static SPA (currently served from s3-cloudfront combo).

*Backend API Client*
We have an api client written in elm that resides with the api server. The 
api-client elm module can be pulled into any elm project that needs to 
communicate with the backend server, and includes all http requests, model 
types, model json decoders, and any necessary model helpers. Importantly, 
this is where authorization and authentication is handled as well. A user 
who successfully signs-in via the api will be granted an authorization 
token. The authorization token must be provided with each following request 
to the api. 

example: https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c

*SPA*
The folder structure for the majority of our elm SPA's end up as follows:
  - Component (folder)
  - Pages (folder)
  - Main.elm
  - Route.elm
  - Routing.elm
  .. any other app/infrastructure related modules

*Route.elm*
Module encapsulating functions relating to routes:
https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-route-elm

*Routing.elm*
The routing module holds the state of the current page, and isolates logic 
pertaining to which page is displayed for each route
https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-routing-elm

*Main.elm*
This is where the top level modules are wired together. It's difficult to 
create a generate example for this since your Main.elm will be application 
specific. Here is a hacked together example of a Main that you can sift 
through and try to understand what's going on in this specific application:
https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-main-elm

Some things to note: The client configuration is stored in the main model 
and passed down into the pages. When a page triggers a logout or login, 
that fact must travel back up to the main module so the client 
configuration state can be adjusted accordingly. If you need to know how to 
do this, I'm happy to explain.

*Pages*
Here is an example page:
https://gist.github.com/eriklott/812a63be9d9cfd6a949cccaa94e6790c#file-page-apples-elm

*Components* 
There are mostly shared headers, footers,menus, that are shared across 
various pages. Some have their own state, but most are simple reusable view 
helpers. 

Sorry for being short on descriptions. Hopefully the examples are enough to 
give you a sense of direction and organization. Happy to answer any 
questions.

On Wednesday, April 19, 2017 at 5:11:05 AM UTC-4, Peter Damoc wrote:
>
> Hello community, 
>
> Scaling Elm apps seams to be a recurring topic. 
>
> I was wondering if maybe we could negotiate a minimal set of 
> functionality, something similar to ToDoMVC, that could be implemented 
> using different approaches to explore what could be the best way to 
> structure the code. 
>
> What should this minimal example cover and what this minimal example 
> should be (topic)?
>
> I'll start the list with some bits of functionality that I would like: 
>
> - multiple pages with common structure (sidebar/navbar)
> - navigation without reloading the app (SPA routing without the hash) 
> - authentication 
> - complex widget reuse (a module/widget that generates side-effects; e.g. 
> a weather widget, some stock ticker, an ad provided by a third party)
> - styling (CSS)
>
> I would also like the example to cover real world concerns of: 
> - using a build manager to integrate with other technologies 
> - development mode - deployment build
> - testing 
>
> As for topic, I was thinking about an interface to the MusicBrainz 
> Database (a simplified interface).
>
> What do you think? 
> What bits of functionality would you like to see exemplified? 
> Are you aware of any other project (in other languages) that exemplifies a 
> minimal set of functionality and could be used as a template?  
>
>
> -- 
> 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.

[elm-discuss] Re: Scaling Elm

[Oliver Searle-Barnes]

Now that I think of I remember that Josh Adams has been working 
on https://github.com/dailydrip/firestorm which is open source and has an 
Elm client. It's written as an SPA so it may serve as a good subject for 
this discussion.

On Wednesday, 19 April 2017 17:21:04 UTC+2, Marek Fajkus wrote:
>
> I would like to help with this by contributing some version.
>
> Anyway it's crucial to point out that this is really not easy thing to do. 
> I like idea with MusicBrainz db but that doesn't include changing data on 
> server. Also it's hard to demonstrate scaling without some noise (unrelated 
> business logic) and the same time do not introduce over-engineering at the 
> process anyone can use against whole idea. At least for me it's hard to 
> imagine scope of this. I also believe this is the reason we there isn't 
> something like this yet.
>
> Honestly ultimate solution would be to start some actually useful OSS 
> project which and solve some real use case. By that I mean something 
> bigger. @Oliver mentioned he has Ember background. In ember there is 
> Discourse and Hospital Run for instance.
> Anyway now I feel I'm asking for too much and have doubts I'll be able to 
> contribute for project like this... sadly... It is just idea that come to 
> my mind.
>
> On Wednesday, April 19, 2017 at 11:11:05 AM UTC+2, Peter Damoc wrote:
>>
>> Hello community, 
>>
>> Scaling Elm apps seams to be a recurring topic. 
>>
>> I was wondering if maybe we could negotiate a minimal set of 
>> functionality, something similar to ToDoMVC, that could be implemented 
>> using different approaches to explore what could be the best way to 
>> structure the code. 
>>
>> What should this minimal example cover and what this minimal example 
>> should be (topic)?
>>
>> I'll start the list with some bits of functionality that I would like: 
>>
>> - multiple pages with common structure (sidebar/navbar)
>> - navigation without reloading the app (SPA routing without the hash) 
>> - authentication 
>> - complex widget reuse (a module/widget that generates side-effects; e.g. 
>> a weather widget, some stock ticker, an ad provided by a third party)
>> - styling (CSS)
>>
>> I would also like the example to cover real world concerns of: 
>> - using a build manager to integrate with other technologies 
>> - development mode - deployment build
>> - testing 
>>
>> As for topic, I was thinking about an interface to the MusicBrainz 
>> Database (a simplified interface).
>>
>> What do you think? 
>> What bits of functionality would you like to see exemplified? 
>> Are you aware of any other project (in other languages) that exemplifies 
>> a minimal set of functionality and could be used as a template?  
>>
>>
>> -- 
>> 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.

[elm-discuss] Re: Scaling Elm

[Marek Fajkus]

I would like to help with this by contributing some version.

Anyway it's crucial to point out that this is really not easy thing to do. 
I like idea with MusicBrainz db but that doesn't include changing data on 
server. Also it's hard to demonstrate scaling without some noise (unrelated 
business logic) and the same time do not introduce over-engineering at the 
process anyone can use against whole idea. At least for me it's hard to 
imagine scope of this. I also believe this is the reason we there isn't 
something like this yet.

Honestly ultimate solution would be to start some actually useful OSS 
project which and solve some real use case. By that I mean something 
bigger. @Oliver mentioned he has Ember background. In ember there is 
Discourse and Hospital Run for instance.
Anyway now I feel I'm asking for too much and have doubts I'll be able to 
contribute for project like this... sadly... It is just idea that come to 
my mind.

On Wednesday, April 19, 2017 at 11:11:05 AM UTC+2, Peter Damoc wrote:
>
> Hello community, 
>
> Scaling Elm apps seams to be a recurring topic. 
>
> I was wondering if maybe we could negotiate a minimal set of 
> functionality, something similar to ToDoMVC, that could be implemented 
> using different approaches to explore what could be the best way to 
> structure the code. 
>
> What should this minimal example cover and what this minimal example 
> should be (topic)?
>
> I'll start the list with some bits of functionality that I would like: 
>
> - multiple pages with common structure (sidebar/navbar)
> - navigation without reloading the app (SPA routing without the hash) 
> - authentication 
> - complex widget reuse (a module/widget that generates side-effects; e.g. 
> a weather widget, some stock ticker, an ad provided by a third party)
> - styling (CSS)
>
> I would also like the example to cover real world concerns of: 
> - using a build manager to integrate with other technologies 
> - development mode - deployment build
> - testing 
>
> As for topic, I was thinking about an interface to the MusicBrainz 
> Database (a simplified interface).
>
> What do you think? 
> What bits of functionality would you like to see exemplified? 
> Are you aware of any other project (in other languages) that exemplifies a 
> minimal set of functionality and could be used as a template?  
>
>
> -- 
> 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: Comments on the TEA Components package

[Marek Fajkus]

First of all I have to say I'm really glad we have this discussion. I know 
it's sometimes frustrated to face different opinions but outcome is 
definitely worth it. It looks like we're really not on same page and can 
learn something from other here. Also it seems that groups are good place 
to do that.

I have quite some points to ongoing discussion but I really have no time to 
put them down now since I have to work on things with colleagues.

Anyway since nobody reacted on @peter's comment and I feel it really needs 
to be addressed let me add my opinion just on that for now:

How about the case where one has calls to a server involved? for example a 
> weather widget or some kind of "Quote of the day" widget, a stocks ticker, 
> etc. 
> How does one handles side-effects (http, random, time etc) with this 
> pattern? 


Creating "components" that  do any kind of HTTP is probably way to hell. 
The only exception are really simple things like let's say jQuery plugins 
or anything which is really really really super isolated.

Generally networking should be on real surface of whole system. There are 
many things that can go wrong. This is the ultimate side-effect since one 
system talking to another over "Maybe Connection" doesn't have any 
guarantees about what that other system does. And you have to assume the 
other system will fail in one way or another. Dealing with failure is 
difficult itself and is hard to do in isolation of system since it pretty 
often has some impact of other things. *Api is the only real "mutable 
object" you have in TEA* (and you can write it in Haskell and do not change 
anything about this fundamental truth)*.* Api is actually global (your 
domain) mutable (even hello word "pure" can return error 500) singleton. 
People with some Erlang experience know costs of fault tolerance. I 
remember in some Evan's comment in Elm's either stdlib or compiler there 
was some note about OTPish (Open Telecom Platform) message passing. Anyway 
even thought Actor model is really great interesting model for concurrency 
it's crucial to understand it leads to some inherited complexity. We surly 
don't want to implement actors in Elm. Rich Hickey (author of Clojure) 
would probably said something like "Adding networking stuff to component is 
completing concerns of how to work with A and how and where to get things A 
needs".

Also getting data is usually not the only thing you need to think of. Say 
you have Blog with posts and you're building admin. There is list of posts 
on left and post detail on right. Now you want to add "delete" function to 
post list so you can click on "delete" button and delete post. The right 
way to do it is emit some action from UI on click (This is what Html.Events 
do for you) and handle it on some very top/surface level - usually update 
but in case of composed updates (like "tea-component") on* the very top one*. 
Why? Because in actions like this you need to really look at system as 
whole. What should happen when user is trying to delete post which is 
actually opened? How can I tell if it's open (probably from route) and so 
on. Only on most top level you can control whole system (even though you 
might use higher lever interfaces of self contain units that if you have 
them).

Of course there are exception but I would rather avoid examples of 
"component that can do http" since this is really where people can hurt 
themselves.

Actually this is precisely why "tea-component" was using that "Action 
Bubbling" and and sending messages to upper component. Component might 
knows how to propagate "delete" action but has no idea about how to proceed 
delete. That is really concern for system as a whole. This is sort of same 
as Html.Events just on higher level. Child just asks "Hey this just 
happened and you might be interested" and system as whole knows how, when 
or if at all to do with it.

This is at least what I thing based on my experience. Hope it makes sense.

On Wednesday, April 19, 2017 at 6:56:23 AM UTC+2, Peter Damoc wrote:
>
> On Wed, Apr 19, 2017 at 2:58 AM, Richard Feldman  > wrote:
>>
>> "Everything ought to have the same API" is a much harder claim to defend. 
>> It sounds wrong at face value, and I haven't seen any evidence (in this 
>> thread or elsewhere) to convince me that it's a wise goal to pursue. :)
>>
>
> But isn't the entirety of the html package and actual example of an 
> unified API? 
> All the widgets there have the same API: widget : List (Attribute msg) -> 
> List (Html msg) -> Html msg
>
>
> checkbox : (Bool -> msg) -> Bool -> Html msg
>
>
>
> How about the case where one has calls to a server involved? for example a 
> weather widget or some kind of "Quote of the day" widget, a stocks ticker, 
> etc. 
> How does one handles side-effects (http, random, time etc) with this 
> pattern?  
>
>
>
>
>
>
> -- 
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>

-- 
You received this message 

[elm-discuss] Re: Source Maps? /was Elm Dev Tools

[Martin Janiczek]

I'm working on code coverage tool, although not in the "source maps + 
Istanbul" way:
https://groups.google.com/forum/#!topic/elm-dev/1tHjTG1z6EM

It currently lives on Github in Janiczek/elm-compiler 
.

https://github.com/Janiczek/elm-make/commit/1497add08e790bc10e004a7cbefb3f5e02527e92
https://github.com/Janiczek/elm-compiler/commit/303068059656e3e983d5d3f490739e220c2bef9e

-- 
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: Scaling Elm

[art yerkes]

That's a pretty good list.  I'd add interacting with sound, files and 
focus, which require side-effect like interaction and haven't really been 
addressed well yet.

On Wednesday, April 19, 2017 at 2:11:05 AM UTC-7, Peter Damoc wrote:
>
> Hello community, 
>
> Scaling Elm apps seams to be a recurring topic. 
>
> I was wondering if maybe we could negotiate a minimal set of 
> functionality, something similar to ToDoMVC, that could be implemented 
> using different approaches to explore what could be the best way to 
> structure the code. 
>
> What should this minimal example cover and what this minimal example 
> should be (topic)?
>
> I'll start the list with some bits of functionality that I would like: 
>
> - multiple pages with common structure (sidebar/navbar)
> - navigation without reloading the app (SPA routing without the hash) 
> - authentication 
> - complex widget reuse (a module/widget that generates side-effects; e.g. 
> a weather widget, some stock ticker, an ad provided by a third party)
> - styling (CSS)
>
> I would also like the example to cover real world concerns of: 
> - using a build manager to integrate with other technologies 
> - development mode - deployment build
> - testing 
>
> As for topic, I was thinking about an interface to the MusicBrainz 
> Database (a simplified interface).
>
> What do you think? 
> What bits of functionality would you like to see exemplified? 
> Are you aware of any other project (in other languages) that exemplifies a 
> minimal set of functionality and could be used as a template?  
>
>
> -- 
> 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: ANN: TypedSvg

[Duane Johnson]

On Tue, Apr 18, 2017 at 7:20 AM, Jakub Hampl  wrote:

> Think of the  element akin to the  element in HTML. Yes, fairly
> often you will simply pass a string to it, but it needing lower level
> styling is pretty common.
>
> For the API you proposed, what would happen if you passed in both a
> non-empty list of svgs and a string?
>

Do you happen to have an example of the  element in use as a parent
node of several child nodes? Up to this point, I've simply used it as a
"label"-like feature of my SVG graphics, where the attributes of the 
element have sufficed to place a single line or label in the correct
location, with the right color etc.

-- 
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] Scaling Elm

[Duane Johnson]

On Wed, Apr 19, 2017 at 3:11 AM, Peter Damoc  wrote:

> - complex widget reuse (a module/widget that generates side-effects; e.g.
> a weather widget, some stock ticker, an ad provided by a third party)
>

Selfishly, a rich text editor with custom elements would be awesome. I'm
trying to figure out how to embed a non-elm widget inside elm (quilljs) and
then elm views inside quilljs.

-- 
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: Scaling Elm

[Oliver Searle-Barnes]

I think this would be fantastically useful :) I've kept out of discussions 
regarding architecture as they've been going in circles for the last 6 
months or so. An example SPA seems like a great way to move forwards.

Something which every SPA I've ever written has included is a Store of some 
sort, an abstraction which mutates/queries for server side records and 
consolidates the results in the client. Perhaps it's my Ember.js background 
but from my perspective this is something that would need to be included.



On Wednesday, 19 April 2017 11:11:05 UTC+2, Peter Damoc wrote:
>
> Hello community, 
>
> Scaling Elm apps seams to be a recurring topic. 
>
> I was wondering if maybe we could negotiate a minimal set of 
> functionality, something similar to ToDoMVC, that could be implemented 
> using different approaches to explore what could be the best way to 
> structure the code. 
>
> What should this minimal example cover and what this minimal example 
> should be (topic)?
>
> I'll start the list with some bits of functionality that I would like: 
>
> - multiple pages with common structure (sidebar/navbar)
> - navigation without reloading the app (SPA routing without the hash) 
> - authentication 
> - complex widget reuse (a module/widget that generates side-effects; e.g. 
> a weather widget, some stock ticker, an ad provided by a third party)
> - styling (CSS)
>
> I would also like the example to cover real world concerns of: 
> - using a build manager to integrate with other technologies 
> - development mode - deployment build
> - testing 
>
> As for topic, I was thinking about an interface to the MusicBrainz 
> Database (a simplified interface).
>
> What do you think? 
> What bits of functionality would you like to see exemplified? 
> Are you aware of any other project (in other languages) that exemplifies a 
> minimal set of functionality and could be used as a template?  
>
>
> -- 
> 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.

[elm-discuss] Scaling Elm

[Peter Damoc]

Hello community,

Scaling Elm apps seams to be a recurring topic.

I was wondering if maybe we could negotiate a minimal set of functionality,
something similar to ToDoMVC, that could be implemented using different
approaches to explore what could be the best way to structure the code.

What should this minimal example cover and what this minimal example should
be (topic)?

I'll start the list with some bits of functionality that I would like:

- multiple pages with common structure (sidebar/navbar)
- navigation without reloading the app (SPA routing without the hash)
- authentication
- complex widget reuse (a module/widget that generates side-effects; e.g. a
weather widget, some stock ticker, an ad provided by a third party)
- styling (CSS)

I would also like the example to cover real world concerns of:
- using a build manager to integrate with other technologies
- development mode - deployment build
- testing

As for topic, I was thinking about an interface to the MusicBrainz Database
(a simplified interface).

What do you think?
What bits of functionality would you like to see exemplified?
Are you aware of any other project (in other languages) that exemplifies a
minimal set of functionality and could be used as a template?


-- 
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: Comments on the TEA Components package

[Peter Damoc]

so, the Model-View-Update triplet *is NOT* the wrong unit of composition
for Elm applications? :)

Don't you see how people starting up with Elm could get confused by this
kind of messages?

On Wed, Apr 19, 2017 at 10:03 AM, Richard Feldman <
richard.t.feld...@gmail.com> wrote:

> > How do you propose to split the functionality one has in a highly
> complex app with a lot of pages without using those triplets?
>
> I don't haha...I just defended their use a few posts ago, complete with
> the specific example of the reusable signup form.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Comments on the TEA Components package

[Richard Feldman]

> How do you propose to split the functionality one has in a highly complex app 
> with a lot of pages without using those triplets?

I don't haha...I just defended their use a few posts ago, complete with the 
specific example of the reusable signup form.

-- 
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: Comments on the TEA Components package

[Peter Damoc]

On Wed, Apr 19, 2017 at 9:19 AM, Richard Feldman <
richard.t.feld...@gmail.com> wrote:

> My point that there's a simple way to scale Elm applications by
> abstracting at the function level has gone uncontested for awhile in this
> thread. I think at this point I've said my piece and might as well move on.
>
> It's cool for people to have philosophical goals separate from the goal of
> a nice scaling experience, but I honestly don't think I have much to
> contribute to those discussions. :)
>
I am genuinely interested in a reasonable answer to the encapsulation of
side-effects components/widgets.
I have tried to think about this when I tried to reimplement the old
tutorial and failed to find a proper solution.
I remember asking about it here (or maybe on Slack) and have no memory of
an answer.

I don't know how to encapsulate the kind of functionality that was
demonstrated in the RandomGif or the SVG Animation with the currently
recommended approach.

It's fine to say, "we don't do it like we used to do it" but there was no
functionally equivalent solution offered.

Also, one could use the old approach to scale by splitting an app into
pages.
I have no idea how to avoid Model-Update-View when implementing the idea of
Pages.

You say:
>
> *we learned that a Model-View-Update triplet is the wrong unit of
> composition for Elm applications.*


How do you propose to split the functionality one has in a highly complex
app with a lot of pages without using those triplets?


-- 
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: Comments on the TEA Components package

[Richard Feldman]

My point that there's a simple way to scale Elm applications by abstracting
at the function level has gone uncontested for awhile in this thread. I
think at this point I've said my piece and might as well move on.

It's cool for people to have philosophical goals separate from the goal of
a nice scaling experience, but I honestly don't think I have much to
contribute to those discussions. :)

On Tue, Apr 18, 2017, 9:56 PM Peter Damoc  wrote:

> On Wed, Apr 19, 2017 at 2:58 AM, Richard Feldman <
> richard.t.feld...@gmail.com> wrote:
>>
>> "Everything ought to have the same API" is a much harder claim to defend.
>> It sounds wrong at face value, and I haven't seen any evidence (in this
>> thread or elsewhere) to convince me that it's a wise goal to pursue. :)
>>
>
> But isn't the entirety of the html package and actual example of an
> unified API?
> All the widgets there have the same API: widget : List (Attribute msg) ->
> List (Html msg) -> Html msg
>
>
> checkbox : (Bool -> msg) -> Bool -> Html msg
>
>
>
> How about the case where one has calls to a server involved? for example a
> weather widget or some kind of "Quote of the day" widget, a stocks ticker,
> etc.
> How does one handles side-effects (http, random, time etc) with this
> pattern?
>
>
>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/Lo6bG96zotI/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.