[elm-discuss] Re: Trouble initializing input with value

[Oliver Searle-Barnes]

If you type some text, move the cursor back a few characters and then type 
quickly the cursor will jump to the end. It's an issue that all VDOM 
implementations have to workaround but as yet Elm doesn't have one. I 
believe there's an issue open for it somewhere but I wasn't able to track 
it down.


On Monday, 7 August 2017 19:56:51 UTC+2, Mickey Vashchinsky wrote:
>
> That is a strange behavior.
> Here is a simplest example, where the cursor stays where it was:
> https://ellie-app.com/3XzqjnmpZg6a1/0
>
> Maybe your scenario is different?
>
>
> On Thursday, June 8, 2017 at 2:25:22 AM UTC+2, Carlos De la Guardia wrote:
>>
>> Howdy all, 
>>
>> I'm creating an Elm version of this app: 
>> https://carlosd.org/cheatsheeter/
>> It's got a bunch of fields users can edit, and which are saved in local 
>> storage. I'm running into a problem trying to produce the following 
>> behavior: when a user opens the app, it should read their data from local 
>> storage, insert it into these text fields, and then the user should be able 
>> to edit the field, close the app, and repeat the process. 
>>
>> The specific problem it that setting an input's value with 'onInput' 
>> resets the cursor position to the end of the field every time they type. If 
>> you don't set the value, then the input is always created empty, rather 
>> than with the desired value.  Perhaps using defaultValue would solve this 
>> 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.

[elm-discuss] Re: HIIT sessions?

[Oliver Searle-Barnes]

Many apologies, a sleepy post to the wrong group...

On Tuesday, 30 May 2017 11:37:14 UTC+2, Roman Frołow wrote:
>
> This mailing list is about 
> https://en.wikipedia.org/wiki/Elm_(programming_language)
>
> On Tuesday, 30 May 2017 00:28:11 UTC+2, Oliver Searle-Barnes wrote:
>>
>> Just about to receive my Wahoo Elemnt and am curious if you can setup 
>> HIIT sessions? I haven't seen much talk about them so I suspect they aren't 
>> supported at the moment. If not is there any intention to add support for 
>> HIIT sessions?
>>
>

-- 
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] HIIT sessions?

[Oliver Searle-Barnes]

Just about to receive my Wahoo Elemnt and am curious if you can setup HIIT 
sessions? I haven't seen much talk about them so I suspect they aren't 
supported at the moment. If not is there any intention to add support for 
HIIT sessions?

-- 
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: Implementing a protocol on top of WebSocket: should I build a effect module ?

[Oliver Searle-Barnes]

You might find https://github.com/saschatimme/elm-phoenix useful to look 
at, it's an effects manager phoenix channels built on top of the websocket 
effects manager.

On Tuesday, 16 May 2017 15:30:18 UTC+1, Christophe de Vienne wrote:
>
> Hi everyone, 
>
> I am attempting to implement the pub/sub NATS (https://nats.io) protocol 
> on top of the WebSocket API as a TEA component. 
>
> I have a hard time finding an API for subscriptions: for each 
> subscription some context must be kept, a unique subscription ID 
> generated and in some case a unique reply subject too, and I would like 
> each subscription to generate custom messages for the component which 
> made it. 
>
> I suspect it would be a lot more natural with an effect module, with 
> which I could (hopefully) write, in any part of the application: 
>
> subscriptions : Model -> Sub Msg 
> subscriptions model = 
> Nats.Subscribe model.endpoint "some.subject" MyMessage 
>
> or, for req/rep (a pub + a short-living sub expecting a result): 
>
> myrequest : Model -> Cmd Msg 
> myrequest model = 
> Nats.request model.endpoint "a.request.subject" MyReply 
>
>
> Another difficulty I have is that in some cases I need to send 2 or 3 
> messages through the websocket, in the right order, but WebSocket.send 
> returns a Cmd. So I have to concat the 3 commands in 1 message, which 
> works but oblige 
>
> Am I wrong being tempted by using an effect module for this kind of module 
> ? 
> If so how can I mimick such an API with a TEA approach  ? 
> If not is there any documentation I can read to get familiar with them ? 
>
> Is there any existing module that does this kind of thing for another 
> protocol ? 
>
> Thanks! 
>
> -- 
> Christophe de Vienne 
>

-- 
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] Literature reviews repo

[Oliver Searle-Barnes]

That's great! 

People have been pretty responsive with calls for examples of code from 
existing projects, would it be worth adding a section to the template?


On Monday, 1 May 2017 17:48:48 UTC+2, Max Goldstein wrote:
>
> Here, I've set up a repo:
>
> https://github.com/elm-community/literature-reviews
>

-- 
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] Literature reviews repo

[Oliver Searle-Barnes]

In https://groups.google.com/forum/#!topic/elm-discuss/yHiAJ_wcG3c Max 
proposes that we put together some literature reviews. If we're to 
collaborate on this effort we'll need to consolidate our investigations 
somewhere. Having seen the success of the RFCS repos for Ember 
 and Rust 
 I wonder if we could use a similar 
model. RFCs for those languages are in the business of proposing a concrete 
API (along with supporting evidence) but the structure of a literature 
review could be a template based around the questions Max posed. 

I believe this would give us an open process that the community can 
contribute to collectively. It would allow newcomers to the language to get 
an overview of what the community is thinking about (saving on the 
countless reruns of feature discussions we have in here) while providing a 
structure and focus that will provide Evan with the information that he 
needs.

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

[Oliver Searle-Barnes]

The pattern we use is to have our Page.update functions return

(model, cmd, storeCmd)

the main update then applies the storeCmd to the Store. (the actual code 
supports a few other things but that's the basic gist of it). Hit me up on 
slack if you want to chat about it.



On Sunday, 30 April 2017 08:45:49 UTC+2, Dustin Farris wrote:
>
> I think I've just had an aha moment with this post.
>
> I am in the process of refactoring my monolith MUV into separate modules 
> with their own MUV for each "page" of my SPA.  Up to this point, I have had 
> a separate Store module with its own Model and Msg types and an update 
> function (no view, obviously).  This has worked well up until now, but 
> after splitting off the pages of my app, it is getting more cumbersome to 
> update the Store in a way that looks nice.
>
> e.g. in my Main.elm I'm ending up with something like
>
> update msg model =
> case msg of
> UserProfilePageMsg msg_ ->
> let
> ( userProfilePageModel, userProfilePageCmd ) =
> UserProfilePage.update msg_ model.userProfilePage
> in
> case msg_ of
> UserProfilePage.StoreMsg msg__ ->
> let
> ( storeModel, storeCmd ) =
> Store.update msg__ model.store
> in
> { model
> | userProfilePage = userProfilePageModel
> , store = storeModel
> }
> ! [ Cmd.map UserProfilePageMsg 
> userProfilePageCmd
>   , Cmd.map StoreMsg storeCmd
>   ]
> _ ->
> { model | userProfilePage = userProfilePageModel }
> ! [ Cmd.map UserProfilePageMsg 
> userProfilePageCmd ]
>
>
> and so on for every page that invokes Store.Msg—which is most pages.
>
> I am thinking that there is a better way, and perhaps Kasey's suggestion 
> of forgoing an in-memory Store on the Model might be it.  I'm still not 
> sure—I do like the snappy feel of a page loading instantly if the data is 
> in memory—even if it might change after a brief consultation with the 
> server.
>
> Dustin
>
>
> On Wednesday, April 19, 2017 at 7:28:06 PM UTC-4, Kasey Speakman wrote:
>>
>> 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". 

Re: [elm-discuss] Re: Moving on

[Oliver Searle-Barnes]

I've been using Elm for about 10 months now and have had an app in 
production for the last 2, I share the general feeling of this thread. 

I've addressed Evan directly here because it's impossible not to when 
discussing these topics, I hope my thoughts are taken as sincere and full 
of respect.

Currently under development are: Elm the language, Elm the web platform 
APIs, Elm tooling and effect managers. Evan is an absolute hero for taking 
on the challenge to reimagine and build all of these different aspects of 
web development and his success to date has inspired a lot of enthusiasm in 
this fledgling community. The challenge can not be overstated though, this 
is a gigantic undertaking, and it currently feels like too much for a 
single individual. 

It seems clear that the community has many experienced and talented 
developers within it's ranks. They've all bought into Evan's vision and I 
believe would be willing to go to great lengths in support of it. While I 
can understand that Evan wants to retain control over what represents his 
gold standard there does seem to be an opportunity to help other developers 
help Evan. At a practical level I see two parts to this:

1) Better javascript interop to allow the community to provide the missing 
web APIs and effect managers (task ports have been mooted on several 
occasions)

2) A development process that encourages the use of packages from the wider 
community _before_ they've had sufficient design attention and matured to 
the point where they may be considered gold standard. The exceptionally 
high quality of the solutions that Evan puts out is a destination that we 
all aspire to. Getting there may take a while though, in the mean time 
people are building apps and having to settle with their own half baked 
solutions which are difficult to share with the community. This situation 
is particularly grevious because the time spent building these half baked 
solutions takes time away from focusing on a single aspect that they could 
develop to a higher standard and share with the community. As an engineer 
it's hard to see this process as efficient and optimal. 

I don't want to be too prescriptive here but one suggestion might be to 
introduce the concept of a quality or status metric for each package e.g. 
exploratory, draft, candidate, ready (those were chosen purely for 
illustrative purposes). This would allow the community to benefit from each 
other's work without requiring any compromise in standards. Versus forcing 
every team to reimplement the same things with ports this seems like a 
distinct improvement (IMHO). Potentially packages could even be kept in an 
entirely different package site until they'd graduated to 
http://package.elm-lang.org/. (this would allow beginners to be kept in a 
safer environment until they needed to reach into the community packages)

Hopefully my thoughts will be taken in the postive light that they're 
intended, I'm a huge fan of Elm and would love to see it go from strength 
to strength. As the opportunity doesn't often present itself I'd like to 
extend a huge thankyou to Evan for all the great work you've been putting 
in!

-- 
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] Resources guiding towards shifting to Functional Thinking

[Oliver Searle-Barnes]

I found this talk really useful coming from an OO 
background, https://www.youtube.com/watch?v=E8I19uA-wGY=youtu.be=1s. 
The code examples are in F# but it's an ML based language and the talk is 
mainly conceptual rather than code heavy.

On Wednesday, 26 April 2017 12:44:17 UTC+2, Jiggneshh Gohel wrote:
>
> Thanks Wojciech. http://elmprogramming.com/ really looks to be a 
> promising resources for learning Elm.
> Thanks for sharing.
>
>
> On Wed, Apr 26, 2017 at 4:05 PM, Wojciech Piekutowski  > wrote:
>
>> I recommend http://elmprogramming.com/. It isn't solely focused on 
>> functional programming, but has great illustrations of some concepts that 
>> could initially be hard to grasp. For example 
>> http://elmprogramming.com/string.html#filtering-a-string
>>
>> On 26 April 2017 at 12:13, Jiggneshh Gohel > > wrote:
>>
>>> Hello,
>>>
>>> I have started learning programming in Elm and gradually I am moving 
>>> ahead with this following the awesome tutorial at 
>>> https://www.elm-tutorial.org/en/ 
>>> . 
>>>
>>> While I am onto it I got a thought that somebody like me coming from 
>>> purely imperative programming background, when need to shift thinking in a 
>>> functional way then are there any specific classic book resources I should 
>>> refer to? I am kind of person who likes to build a strong foundation and am 
>>> more inclined towards learning on the path instead of targeting just the 
>>> end. So requesting to provide suggestions considering this.
>>>
>>> I did searched on web and found various links related to few books but 
>>> majority of those were either language-specific like Javascript, ML, 
>>> Scheme, Erlang, Elixir, Haskell, Scala, Clojure, F# etc or mostly 
>>> mathematical-notation based.  So I am really confused which ones to 
>>> consider.
>>>
>>> Thanks.
>>>
>>> 
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to elm-discuss...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
>> 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/9d91xF94cWA/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

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

[Oliver Searle-Barnes]

You've definitely given me some great advice along the way, I'm very 
grateful!

I feel like this discussion has covered a few different scaling techniques 
and I feel like there's a good time to use all of them. Perhaps it would be 
good to just catalogue the different approaches along with some examples 
where people have found them useful in their projects.


On Thursday, 20 April 2017 21:20:47 UTC+2, Richard Feldman wrote:
>
> Thanks Oliver! That's super helpful. <3
>
> as well as providing a fully integrated UI which includes all of the 
>> features, we will also allow individual features to be embedded within 
>> particular pages e.g. an article might have a discussion embedded at the 
>> end, but that same discussion mini-app is also  included in a view more 
>> closely resembling Slack with a sidenav etc...Each mini-app is then 
>> responsible for it's own lifecycle (e.g. Loading/Loaded/Error).
>
>
> I apologize for giving you advice that led to a design that didn't work 
> well for the mini-app business requirements, but I'm really glad to hear 
> you were able to refactor it into a happy place! I can also appreciate that 
> you liked how this worked in broader contexts. :)
>
> That said, based on your note of *"reusable view modules, may include any 
> combination of view/update/Model but few have their own update/Model" - *it 
> sounds like we are approximately on the same page with regards to reuse. ;)
>

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

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

This is a fairly high view of our app and how it's architected but 
hopefully it's a useful level of detail (I've mentioned it a couple of 
times already but here's a rough gist of the folder/file structure we use 
https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec). 

To give you a bit of our context our product is an embeddable web app that 
adds discussion rooms and news feeds to your website. We have Phoenix on 
the backend and we're using elm-phoenix for integration in the client. As 
well as providing a fully integrated UI which includes all of the features, 
we will also allow individual features to be embedded within particular 
pages e.g. an article might have a discussion embedded at the end, but that 
same discussion mini-app is also  included in a view more closely 
resembling Slack with a sidenav etc. 

These requirements led us to an architecture where we have a single Store 
which handles data synchronisation and then several mini-apps which use 
this Store. The Store responsibilities include: subscribing to data feeds 
from the backend, caching results, mutating data in the backend and latency 
compensation (otherwise known as optimistic UI). At the top level these 
mini-apps are organised into complete pages. The pages themselves don't do 
much, they're mapped to urls and combine a set of mini-apps. Each mini-app 
is then responsible for it's own lifecycle (e.g. Loading/Loaded/Error). 

While the requirements have forced have led us towards the mini-apps design 
we've found that they're a great way to organise the codebase, developers 
can concentrate on a particular mini-app and get up to speed very quickly. 

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

Yes we spoke about how the idea of having "sections" within a page that 
function as independent units. The idea of mini-apps seems to encompass the 
approach of splitting out the app into Pages and page Sections. I don't 
have time now but I'll try to put down a description of our app later on 
today. ICYMI I posted a gist of the rough folder/file structure we use 
at https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec

On Thursday, 20 April 2017 06:49:22 UTC+2, Richard Feldman wrote:
>
> 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] 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 

[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

[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] Unsafe mechanism

[Oliver Searle-Barnes]

(prompted by discussion of firebase integration on elm-dev)

Given that it would be really helpful to have more integration libraries 
available for Elm (auth0, firebase, aws...) I've been wondering if the 
current state of affairs is ideal for achieving:

1) Maximum number of integration libraries available for Elm
2) All of those implemented in pure Elm

Currently the path to get there appears to be:

1) Use an existing javascript library and wrap it using ports
2) Reimplement the library in Elm

1 to 2 often represents a significant amount of development. Because ports 
preclude a library from being published in http://package.elm-lang.org/ and 
elm package doesn't support installing them from anywhere else there's a 
social pressure to not implement effect managers or release libraries that 
make use of ports. 

Another path get to pure Elm libraries might be

1) Use an existing javascript library and wrap it using ports or native 
functions
2) Release it as a library
3) Gradually migrate the library over to pure Elm with the help of any 
members of the community that need it

The concern here is obviously that your Elm code can now blow up and 
there's no way of knowing which code is unsafe. 

What if unsafe because a first class concept in Elm? You could mark 
functions as "unsafe". Any function that calls an unsafe function would 
also be required to be declared as unsafe  e.g.


unsafe attemptAuth : LoginDetails -> Task String AuthStatus
unsafe attemptAuth loginDetails =
Native.WrappedLibrary.attemptAuth loginDetails




type Msg
= unsafe AuthResponse (Result String AuthStatus)



unsafe update : Msg -> Model -> (Model, Cmd Msg)
unsafe update msg model =
case msg of
AuthResponse status ->




This would make it possible to do a first pass on integration by just 
delegating to the javascript implementation. It's now very clear which of 
your Elm code is safe and unsafe. Having that unsafe keyword not only let's 
you know which code carries the Elm safety guarantees (if a function isn't 
marked unsafe) but you now also have this unsafe keyword stinking up your 
code encouraging you to reimplement it in pure Elm. You're using a shared 
library now though so whenever you replace a javascript implementation with 
a safe Elm version everyone benefits.

What do you think, does this offer a practical route to a greater number of 
pure Elm integration libraries?







-- 
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: Local third-party packages

[Oliver Searle-Barnes]

What do you think to using the version from the elm-package.json in the 
cloned repo? That way it's as though you'd specified a hard constraint in 
elm-package.json (e.g. 1.2 <= v <= 1.2) and then you can follow the usual 
semantics.


On Thursday, 2 February 2017 07:48:48 UTC+1, Gusztáv Szikszai wrote:
>
> Hey, author of elm-github-install here.
>
> it resolves the git ref then pulls the version number in from it's 
>> elm-package.json
>
> This is basically how it works and it adds the ref as the build number 
> `1.0.0+master` , so this way it tracks what version to resolve and what 
> code to use eventually.
>
> As I read this thread this morning, I realized that I can make the local 
> repositories work along with using different named repositories (forks) for 
> a package. I threw together a prof of concept for it:
> https://github.com/gdotdesign/elm-github-install/pull/14
>
> The basic method works:
> {
>   "dependencies": {
> "elm-lang/svg": "2.0.0 <= v < 3.0.0",
> "elm-lang/dom": "1.1.1 <= v < 2.0.0",
> "elm-lang/core": "5.0.0 <= v < 6.0.0"
>   },
>   "dependency-sources": {
> "elm-lang/core": {
>   "url": "file:///path-to/elm-lang/core",
>   "ref": "master"
> }
>   }
> }
>
> However I'm stuck a little and I would appreciate your thoughts on how to 
> handle transitive versions: what are the priorities when dealing with 
> different versions, this is what I am suggesting:
>
>- 2 - current packages dependency - if the current package (the one we 
>are installing dependencies for) sets a source it will be the one we use
>- 1 - packages dependency - if the current package doesn't have 
>dependency for a package but an other has we use that 
>- 0 - Github - if no package defines dependency for a package we fall 
>back to Github
>
> Let me know if you are trying this branch out.
>
> On Wednesday, February 1, 2017 at 10:57:43 PM UTC+1, Oliver Searle-Barnes 
> wrote:
>>
>> elm-github-install has a separate dependency-sources section which you 
>> can use to override the dependency versions. The readme has the following 
>> example
>>
>>   "dependencies": {
>> "gdotdesign/elm-install-test": "1.0.0 <= v < 2.0.0",
>> "elm-lang/core": "5.0.0 <= v < 6.0.0",
>> "elm-lang/svg": "2.0.0 <= v < 3.0.0",
>> "elm-lang/dom": "1.1.1 <= v < 2.0.0"
>>   },
>>   "dependency-sources": {
>> "elm-lang/core": "g...@github.com:elm-lang/core",
>> "gdotdesign/elm-install-test": {
>>   "url": "gdotdes...@bitbucket.org:gdotdesign/elm-install-test",
>>   "ref": "master"
>> }
>>   }
>>
>>
>> So you would specify your file:///uri in the "url" property and whatever 
>> git treeish value you want in "ref" (e.g. master). I'm not entirely sure 
>> how it works in the case that you override a transitive dependency. It may 
>> just ignore semantic versioning completely and use the version you've 
>> specified in the git reference or perhaps it resolves the git ref then 
>> pulls the version number in from it's elm-package.json. Because Elm uses a 
>> flat dependency structure specifying the dependency explicitly will be 
>> enough to constrain the transitive version as well.
>>
>>
>> On Wednesday, 1 February 2017 17:58:34 UTC+1, Rupert Smith wrote:
>>>
>>> On Wednesday, February 1, 2017 at 4:57:22 PM UTC, Rupert Smith wrote:
>>>>
>>>> This is actually something I have been wondering how to do because I 
>>>> wanted to do some hacking on elm-lang/virtual-dom, but I have no idea how 
>>>> to import the hacked version into another project in order to try it out.
>>>>
>>>
>>> Also, one does not normally include elm-lang/virtual-dom explicitly, it 
>>> gets sucked in as a transitive dependency of elm-lang/html or elm-lang/svg. 
>>> Is it possible to override transitive dependencies? 
>>>
>>

-- 
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: Local third-party packages

[Oliver Searle-Barnes]

elm-github-install has a separate dependency-sources section which you can 
use to override the dependency versions. The readme has the following 
example

  "dependencies": {
"gdotdesign/elm-install-test": "1.0.0 <= v < 2.0.0",
"elm-lang/core": "5.0.0 <= v < 6.0.0",
"elm-lang/svg": "2.0.0 <= v < 3.0.0",
"elm-lang/dom": "1.1.1 <= v < 2.0.0"
  },
  "dependency-sources": {
"elm-lang/core": "g...@github.com:elm-lang/core",
"gdotdesign/elm-install-test": {
  "url": "gdotdes...@bitbucket.org:gdotdesign/elm-install-test",
  "ref": "master"
}
  }


So you would specify your file:///uri in the "url" property and whatever 
git treeish value you want in "ref" (e.g. master). I'm not entirely sure 
how it works in the case that you override a transitive dependency. It may 
just ignore semantic versioning completely and use the version you've 
specified in the git reference or perhaps it resolves the git ref then 
pulls the version number in from it's elm-package.json. Because Elm uses a 
flat dependency structure specifying the dependency explicitly will be 
enough to constrain the transitive version as well.


On Wednesday, 1 February 2017 17:58:34 UTC+1, Rupert Smith wrote:
>
> On Wednesday, February 1, 2017 at 4:57:22 PM UTC, Rupert Smith wrote:
>>
>> This is actually something I have been wondering how to do because I 
>> wanted to do some hacking on elm-lang/virtual-dom, but I have no idea how 
>> to import the hacked version into another project in order to try it out.
>>
>
> Also, one does not normally include elm-lang/virtual-dom explicitly, it 
> gets sucked in as a transitive dependency of elm-lang/html or elm-lang/svg. 
> Is it possible to override transitive dependencies? 
>

-- 
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: Local third-party packages

[Oliver Searle-Barnes]

elm-install is using the ruby-git gem which supports local git URIs of the 
form file:///path/to/local/remote.git

On Tuesday, 31 January 2017 11:00:13 UTC+1, Rupert Smith wrote:
>
> On Monday, January 30, 2017 at 6:48:13 AM UTC, Lyle Kopnicky wrote:
>>
>> What's the best way of referencing third-party packages in another 
>> directory on the same machine?
>>
>
> It would be nice if there was a way to do this - either by extending 
> elm-github-install or elm-install. The use cases I would like to see 
> covered are:
>
> Installing from a git repo other than GitHub.
> Being able to build an elm project and 'install' a copy of it to some 
> local repository (doesn't need to be anything more fancy than a directory 
> on the local file system) and reference it from there.
> Being able to work with a 'development' version of a library. That is, 
> rather than version 2.2.0, I'd like to be able to reference 2.2.0-SNAPSHOT 
> (like Maven) or LATEST, or 2.2.0-LATEST or something like that.
>
> I ran into this problem when I pulled out some of my native code into its 
> own repository. When I want to consume that in another project, I use 
> elm-github-install to reference it. Then I wanted to experiment with a new 
> feature (just a couple of lines), and I ended up pushing that back to 
> GitHub and tag it, just to try it out.
>
> When Evan says he is working on 'packaging' for the 0.19 release, are 
> these things that are going to be addressed? I got the impression from a 
> recent update on elm-dev that 'packaging' is actually talking about how the 
> compiled code is packaged for inclusion in a web-page, to allow code re-use 
> instead of compiling everything to one big .js file, rather than how the 
> package management system works. It would be good to get some clarity on 
> this, as perhaps enhacing elm-github-install could be a useful area to 
> contribute to if it is not already planned.
>

-- 
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] Building a Store without boilerplate

[Oliver Searle-Barnes]

Thanks for your elm-sapling example, that's an idea that I hadn't 
considered, I think it falls into approach (2) that I mentioned above. 

> I don't think that's possible. 

I have noticed that Haskell has solutions for this problem 
e.g. https://github.com/yesodweb/persistent. In that case it's using 
Template Haskell which I'm not familiar with but appears to be a meta 
programming framework for Haskell. Elm doesn't support anything like this 
natively which is why I was considering approach (3) using an external tool 
to do code generation. Aside from Haskell there's also examples of 
persistence frameworks with other statically typed languages such as Java 
and Scala, in those cases introspection is available so solutions tend to 
lean on those.


On Monday, 30 January 2017 12:03:07 UTC+1, Peter Damoc wrote:
>
>
>
> On Mon, Jan 30, 2017 at 12:17 PM, Oliver Searle-Barnes <oli...@opsb.co.uk 
> > wrote:
>
>> # Building a Store without boilerplate
>>
>
> I don't think that's possible. 
> Elm is a static language and what you seam to want is dynamic behavior. 
>
> The practical way to solve this is to ferry type information and use that 
> type information to generate the dynamic behavior.  
> In Elm, this is done with the help of Json.Decode/Json.Encode 
>
> This way, you can take a concrete Elm type, convert it to a generic type 
> like Value or String, do something dynamic based on the info you encode in 
> this generic type, get a generic result back and convert the result back 
> into some concrete Elm type. 
> so you can have something like: 
>
> doSomethingDynamic : a -> (a -> Value) -> Decoder b -> b
> doSomethingDynamic payload encoder decoder = 
> ...
>
> Have you seen how I have approached the issue in the exploration bellow? 
> https://github.com/pdamoc/elm-sapling
>
>
> -- 
> 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] Building a Store without boilerplate

[Oliver Searle-Barnes]

# Building a Store without boilerplate

The app that I’ve been building has a Store abstraction which is built on 
top of elm-phoenix (websockets). Typical methods in the API are:

Store.addProject projectAttributes store
Store.renameProject projectId name store
Store.deleteProject projectId store
Store.getProjectUsers projectId store # relationship traversal

The Store also handles latency compensation, so that for instance when you 
add a project it appears to the client that it has been added successfully 
even before a message has been sent to the server. Once the server confirms 
the operation is then confirmed/rejected in the client.

While I'll happy with how the Store works, it does involved writing an 
absolute ton of boilerplate code. Every single method in the Store API 
needs to be hand written at every layer, updating the Store's internal 
model, the latency compensation and the serialisation.

---

So the question is, in a statically typed language, with no introspection 
how would one go about avoiding this duplication?

The two possibilities I've considered so far are:

1) Somehow do it in Elm, I'm struggling to see how it's possible, this 
would be my preferred option though :)

2) Define everything dynamically inside the Store, i.e. use Dicts 
everywhere instead of static types. Then provide the Store with a mapping 
which takes care of translating between the static and dynamic structures. 

Having to forgo static types is obviously disappointing with this route.

3) Code generation - lots of options here, could be inline macros in the 
Elm code, a custom DSL or code defined in another language. 

How would this sort of problem typically be solved in an ML language? Has 
anyone tried something similar 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: Pseudo Web Components in Elm

[Oliver Searle-Barnes]

Thank you for putting this together Peter, it's certainly something that 
I've given more than a little thought to. While I believe that sticking to 
a flat structure where possible is beneficial there really does seem to be 
a place for components like text editors, calendars etc. I'll try to give 
it a good look in the coming days. Thanks again!




On Saturday, 21 January 2017 17:14:48 UTC+1, Peter Damoc wrote:
>
> Hi Berry,
>
> You understand correctly, that's the intended way of composing.
>
> I have not thought seriously about themability but it should be possible 
> through the use of shared CSS (elm-css).
>
> The CounterList example shows how the counters push data into the parents 
> through events.
>
> Boxes can exist within boxes. AltMain shows this (it is a box that 
> contains other boxes)
>
> Please add an issue about Safari in the repository. I'll investigate it 
> when I get back to a computer (I'm on my mobile now).
>
> Thank you for the feedback!
>
>
> On Sat, 21 Jan 2017 at 16:34, Berry Groenendijk  > wrote:
>
>> Hi Peter,
>>
>> If I understand correctly, a box is basically a mini-main. And boxes can 
>> be composed into one big main. I like the resulting code, like:
>>
>> main : Html msg
>> main =
>> div []
>> [ counter [ value 4 ] []
>> , counter [ value 2 ] []
>> ]
>>
>> The result is a very easy composable main. Questions that come to mind 
>> are:
>>
>> - Theme-ability: can components adhere to a general CSS theme?
>> - And I did not see an example where information from one component is 
>> used in another. How would that look like? Can a box store information in a 
>> model in main, for example? I imagine a form box that gathers information 
>> from a user (including validation, etc.) and if form is valid the 
>> information is stored in the model in main. And some other component uses 
>> this information to show the data.
>> - Can boxes exist within boxes?
>>
>> PS: the example runs in chrome. But, in Safari I get the following error:
>>
>>
>> 
>>
>> Which is line 162 in box.js.
>>
>> Thanks!
>>
>> Berry
>>
>>
>> Op zaterdag 21 januari 2017 10:43:09 UTC+1 schreef Peter Damoc:
>>
>>> Hello Community, 
>>>
>>> I've worked the last few days to bring about an older dream of mine: 
>>> converting Elm programs into Html elements with the intention of composing 
>>> them. 
>>>
>>> The route I took was that of the pseudo Web Components. 
>>>
>>> Here is the library that I made:
>>> https://github.com/pdamoc/elm-box
>>>
>>> It is implemented with Native so, don't expect to see it in the packages 
>>> repository any time soon but I think this is an important topic and should 
>>> be explored by more people. 
>>>
>>> The Readme has instructions for both playing with it and for testing it 
>>> in toy projects. 
>>>
>>> The examples folder has a bunch of examples showing how I view 
>>> implemented the old elm-architecture-tutorial examples using Boxes. 
>>>
>>> The examples range from extremely simple to a more fancy example that 
>>> integrates with elm-css. 
>>>
>>> The API has passed through a few iterations and I think it is quite OK 
>>> but if you have suggestions for improvements please contribute. 
>>>
>>> There are, of course, a lot issues and caveats due to this being a quick 
>>> and dirty implementation BUT, it think the code is good enough to be used 
>>> to start this discussion. 
>>>
>>> This is a very dear topic to me so, any questions or comments are 
>>> appreciated.
>>>
>>> Thank you. 
>>>
>>> -- 
>>> 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...@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: Feature: 'where' expressions (continued from GitHub)

[Oliver Searle-Barnes]

As a non haskeller I do find my something constantly wishing that where 
expressions had been chosen instead if let/in. Let/in leads to a sort of 
vertigal zig zagging as you need to jump to the bottom then scan backwards for 
the supporting information. In other languages I've always ordered my methods 
as per the where expression (I think it was a practice I picked up from Kent 
Beck who recommended it for readability) and while I can order my functions 
this way at the module level I do miss it with let/in. The pattern Joey 
suggests seems good, the counter argument though is that you need to check the 
'in' to know if that pattern is being used so you end up doing the zig zag read 
anyway. 

That being said I favour the simplicity of a single form, I just wish where had 
been chosen instead of let/in. The argument regarding being able to use let/in 
with anonymous functions seems irrelevant as it's use would be a clear sign 
that the function should be broken out into a named function.

-- 
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: Introducing Firestorm - An Elm-powered forum engine built atop Elixir and Phoenix

[Oliver Searle-Barnes]

I thought the concept was great in the first place so I ponied up a while 
back. I would have gladly paid just for the exploration of webcomponents 
though, very much looking forward to seeing that :)

On Wednesday, 14 December 2016 20:41:05 UTC+1, Josh Adams wrote:
>
> tl;dr
>
> DailyDrip is building an open-source forum engine with an Elm frontend. 
>  We’re doing it via a Kickstarter campaign that has just 8 days remaining 
> .  We’d love your support!  More details below.
> Details
>
> [image: firestorm.jpg]
>
> There isn’t a good alternative to Google Groups for forums, and there 
> should be an easy open source alternative for comment systems.  An Elm 
> frontend is a no-brainer.
>
> The Kickstarter closes on December 22. Starting in January we will spend 
> the first month doing weekly design and planning meetings with our 
> supporters. We will also share the plans and designs along the way. We 
> would love feedback on the project early on from our backers.  After the 
> design process we’ll spend a few weeks building out the initial backend and 
> basic HTML views. We want Firestorm to be accessible to people that don’t 
> know Elm, just want a good Phoenix example application, or don’t enable 
> JavaScript. After the backend and API are completed, we will build an Elm 
> interface that replaces the existing HTML and provides a richer experience 
> to the end user as a Single Page Application. 
>
> [image: phoenix_and_elm.png]
>
> We plan on building Firestorm using Web Components - my recent experiments 
> with them have been extremely promising and should be a really modular way 
> to build out the front end.
>
> You can find more details at the Kickstarter campaign site 
> .
>
> Thanks!
>
> Josh Adams
> Co-Founder, DailyDrip
>

-- 
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: Using flat-file JSON fixtures in elm-test and API tests

[Oliver Searle-Barnes]

This is a slightly different approach to the problem but thought you might 
be interested to see it, https://github.com/realestate-com-au/pact.

On Monday, 12 December 2016 00:16:21 UTC+1, Jan Fornoff wrote:
>
> Hi everyone!
>
> I'd like to propose an idea that I've been playing with for a bit.
>
> *Core problem:*
>
> Testing an API is not too challenging, and the tests are pretty fast too 
> (e.g., controller and unit tests in Ruby on Rails).
> Verifying that an Elm frontend works is fairly straightforward as well and 
> fast (with elm-test).
>
> To ensure that the interactions between Elm and the API work as intended, 
> one approach is to utilize an End-To-End testing approach (such as 
> simulating user interaction through PhantomJS, Selenium or similar).
> However, those tests are slow and therefore a tradeoff between test suite 
> runtime and amount of test cases needs to be made.
>
> *Possible solution:*
>
> Given the constraints above, it is a prudent approach to focus End-To-End 
> tests to the more mission-critical features of an application.
> In my experience, such tests mostly verify that everything is plugged 
> together correctly and works "at first sight" (i.e., not exploring every 
> last bit of functionality).
>
> Compatibility between the frontend application and the API endpoints being 
> used is a point where bugs can easily sneak in and increase the desire for 
> E2E tests.
>
> To deal with this, a possible solution might include sharing fixtures 
> between API and frontend tests, such that:
> - API tests verify that responses conform with a JSON fixture file
> - Frontend test use the same JSON fixture files as "stubbed" API responses
>
> I've created a small infographic illustrating the idea with an example right 
> here .
>
>
> Please let me hear your thoughts on this! :-)
> Best regards,
> Jan
>

-- 
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: Any other implementations of elm-test runners besides rtfeldman/node-test-runner?

[Oliver Searle-Barnes]

There's also https://github.com/rtfeldman/html-test-runner (yep, that would 
be Richard again :) )

On Friday, 2 December 2016 17:24:18 UTC+1, Rupert Smith wrote:
>
> Any other implementations of elm-test runners besides 
> rtfeldman/node-test-runner?
>

-- 
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] Documentation on Effects Managers

[Oliver Searle-Barnes]

Hey cloudie, I started a project yesterday for adding optimistic ui on too of 
elm-phoenix. It's very much a sketch at the moment (although working at least), 
you can take a look at 
https://github.com/opsb/elm-optimist/tree/initial-example?files=1. I'm curious 
what you've got
in mind with the effect manager. What's your general approach going to be?

-- 
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] Documentation on Effects Managers

[Oliver Searle-Barnes]

Hey cloudie, I started a project yesterday for adding optimistic ui on too of 
elm-phoenix. It's very much a sketch at the moment (although working at least), 
you can take a look at 
https://github.com/opsb/elm-optimist/tree/initial-example?files=1. I'm curious 
what you've got
in mind with the effect manager. What's your general approach going to be?

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

Re: [elm-discuss] What Elm needs to move forward

[Oliver Searle-Barnes]

Something that I feel isn't acknowledged is that it's ok to have a language 
with more advanced features for library authors than library consumers. I 
don't see that it follows that having more advanced features makes the 
language harder to use for beginners (I'd argue the opposite even). I do 
see your point though that allowing more powerful abstractions and 
maintaining ease of use is perhaps something that more powerful FP 
languages have failed (or not attempted even) to find and careful and 
patient thought is required. 


On Thursday, 24 November 2016 11:45:38 UTC+1, John Orford wrote:
>
> Oliver,
>
> I understand. But... we are swimming in a sea of imperative programmers. A 
> lot of FP is not obviously better for them.
>
> From my POV, this is Elm's greatest strength and weakness.
>
> It would be so easy to be a PureScript and corner a hardcore niche, where 
> 'power' is everything.
>
> Elm has a larger goal - to bring FP to the masses. 
>
> I am sure abstractions will come in good time, but they will be added 
> carefully with a lot of thought.
>
> So... I totally understand, but there's not a lack of 'powerful' FP out 
> there, there's a lack of FP for the masses.
>
> This is extremely challenging in all sorts of ways, and an open question 
> of whether it's even possible.
>
> But this I believe is what Elm is aiming to do.
>
> Who knows whether it will fail or not. No one really knows. I know it's 
> worth a shot though!
>
> John
>
> On Thu, 24 Nov 2016 at 11:34 Oliver Searle-Barnes <oli...@opsb.co.uk 
> > wrote:
>
>> I'm definitely still in the process of moving my thinking into a 
>> functional approach (currently working through Programming Haskell and 
>> Bartosz 
>> Milewski <https://www.youtube.com/user/DrBartosz>'s Category Theory 
>> series on youtube, both recommended by other Elmers so thanks!). The lack 
>> of abstraction in Elm does seem like a major stumbling point at the moment, 
>> the problems I mentioned above are abundantly obvious for anyone that 
>> starts to use it (I say this with big love for Elm). I want more people to 
>> be able to enjoy Elm but these issues make it very difficult for beginners 
>> or even mid-level developers to get going quickly. 
>>
>>
>> On Thursday, 24 November 2016 11:00:36 UTC+1, Peter Damoc wrote:
>>
>>> On Thu, Nov 24, 2016 at 11:17 AM, Oliver Searle-Barnes <
>>> oli...@opsb.co.uk> wrote:
>>>
>>>> The fact remains though that I don't feel I can offer a sound 
>>>> justification as to why it's far more complicated to do these things in 
>>>> Elm. Elm strives to be easy for users to understand, in this area it is 
>>>> decidedly more complicated than the existing alternatives.
>>>>
>>>
>>> The class of problems you described is precisely the class of problems 
>>> that Object Oriented Programming solves easily. 
>>> It is the class of problems where, as a library developer, you provide 
>>> and API and you allow the client to do multiple implementation of an 
>>> interface, (e.g. the interface of a web-component or the interface of a 
>>> debounceable app). 
>>>
>>> Implementing something that solves this issue is non-trivial because it 
>>> can be a source of chaos (complexity).  
>>> Approaching the Expression Problem 
>>> <https://en.wikipedia.org/wiki/Expression_problem> Elm chose defer 
>>> solving it for later implementing only a few practical facilities like 
>>> toString (allows extension of cases without recompilation) 
>>>
>>>
>>>
>>> -- 
>>> 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...@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] What Elm needs to move forward

[Oliver Searle-Barnes]

I'm definitely still in the process of moving my thinking into a functional 
approach (currently working through Programming Haskell and Bartosz Milewski 
<https://www.youtube.com/user/DrBartosz>'s Category Theory series on 
youtube, both recommended by other Elmers so thanks!). The lack of 
abstraction in Elm does seem like a major stumbling point at the moment, 
the problems I mentioned above are abundantly obvious for anyone that 
starts to use it (I say this with big love for Elm). I want more people to 
be able to enjoy Elm but these issues make it very difficult for beginners 
or even mid-level developers to get going quickly. 


On Thursday, 24 November 2016 11:00:36 UTC+1, Peter Damoc wrote:
>
> On Thu, Nov 24, 2016 at 11:17 AM, Oliver Searle-Barnes <oli...@opsb.co.uk 
> > wrote:
>
>> The fact remains though that I don't feel I can offer a sound 
>> justification as to why it's far more complicated to do these things in 
>> Elm. Elm strives to be easy for users to understand, in this area it is 
>> decidedly more complicated than the existing alternatives.
>>
>
> The class of problems you described is precisely the class of problems 
> that Object Oriented Programming solves easily. 
> It is the class of problems where, as a library developer, you provide and 
> API and you allow the client to do multiple implementation of an interface, 
> (e.g. the interface of a web-component or the interface of a debounceable 
> app). 
>
> Implementing something that solves this issue is non-trivial because it 
> can be a source of chaos (complexity).  
> Approaching the Expression Problem 
> <https://en.wikipedia.org/wiki/Expression_problem> Elm chose defer 
> solving it for later implementing only a few practical facilities like 
> toString (allows extension of cases without recompilation) 
>
>
>
> -- 
> 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] What Elm needs to move forward

[Oliver Searle-Barnes]

I'm going to touch on a couple of sensitive areas here, hopefully you'll 
take my comments in the manner they're intended, to try and expose problems 
that newcomers from other frameworks face so that we can think about how we 
might improve the situation.

I've been using Elm a good portion of the working week for about 3 months 
now, I'm still very much missing a solution for components (to be clear I'm 
talking about an equivalent to WebComponents). Every framework that 
developers come from has a solution for this, with a huge number of 
components available that you can just drop into your app. At the moment 
it's a brick wall that you hit with no real answers. I'm not going to dig 
into the details of the topic here (I have my own workarounds which are 
working in a not ideal way), but it manifests in a few ways. 

1) The only selection of ready to go components available is elm-mdl and it 
requires a technique which is at odds with the recommended architecture.  

2) The level of interest in WebComponents - seems viable but is a long way 
from being a recommended route and is unclear if it would ever be accepted 
as a first class part of the Elm experience.

3) The amount of boilerplate required to integrate a package, 
e.g. http://package.elm-lang.org/packages/jinjor/elm-debounce/latest vs for 
instance https://github.com/nkbt/react-debounce-input 
or https://github.com/offirgolan/ember-debounced-input-helpers.

I'm familiar with all of the arguments and have applied various techniques 
in my own app and have workable solutions. The fact remains though that I 
don't feel I can offer a sound justification as to why it's far more 
complicated to do these things in Elm. Elm strives to be easy for users to 
understand, in this area it is decidedly more complicated than the existing 
alternatives. I personally believe a good experience for beginners requires 
library authors having access to more abstraction (whether it be via type 
classes or whatever), as shown by the debouncer example we currently force 
library consumers to do more work than they'd be used to in other 
environments. 

Elm is fantastically easy to learn, but currently it does seem to come at 
the cost of being hard to use to build SPAs (the learning curve between 
learning the language and knowing how to build a complex app is not only 
steep but also undefined). Can we improve the experience of building SPAs 
without sacrificing how easy it is to learn Elm? 




On Thursday, 24 November 2016 09:41:22 UTC+1, Noah Hall wrote:
>
> I had submitted a couple of talks on advance Elm usage for elm-conf, 
> but sadly that never happened. I have however talked about this kinda 
> thing in local meetups and in the remote meetup. Sadly the most 
> interesting and relevant one (on how to not get blocked with Elm in 
> production) failed to record correctly. These are the kind of talks 
> that I've been heavily recommending elm-conf should focus on. There 
> are so many intro to elm talks. 
>
> Maybe elm-conf EU will have more focus on that. 
>
>
>
> On Thu, Nov 24, 2016 at 7:58 AM, Zachary Kessin  > wrote: 
> > I think we are only differing on the details. We could use talks / 
> blogposts 
> > on all of those things. If you want to write a guest blogpost on any of 
> the 
> > above I would be happy to put it on my blog. 
> > 
> > 
> > Zach 
> > 
> > On Thu, Nov 24, 2016 at 9:31 AM, Peter Damoc  > wrote: 
> >> 
> >> I beg to differ. 
> >> There are a lot of intro talks to Elm syntax and some of them touch a 
> >> little bit on some libraries but we are doing very poorly in addressing 
> >> important concerns like styling, persistence or deployment. 
> >> Of course, one might argue that this falls outside of Elm concerns but 
> >> should it be outside of Elm's concerns? 
> >> Are we trying to build reliable webapps or are we trying to reliably 
> >> generate html? 
> >> 
> >> The domain covered by CSS is virtually unexplored in Elm. It is taken 
> as a 
> >> given that people will solve this on their own using previous knowledge 
> or 
> >> by learning CSS somewhere else. 
> >> There are a few libraries that attempt to address this but most of them 
> >> are bindings to CSS with a little bit of type safety thrown in and do a 
> very 
> >> poor job at documenting use-cases. 
> >> 
> >> The topic of reusable components is still in limbo. 
> >> If someone asks me how would they do a dropdown in Elm I still don't 
> know 
> >> what to say (other than implement it from scratch). 
> >> Have the sortable-table solution and the auto-complete examples been 
> >> imitated? Do we have a large pool of reusable UI elements? 
> >> 
> >> The topic of build tools and end-to-end development, again... it rests 
> on 
> >> people reusing outside knowledge. 
> >> There is very little documentation on producing a deliverable. 
> >> 
> >> Were do we want to be in 3 years time? 
> >> How would we want Elm to have changed the 

[elm-discuss] Re: Tag new releases in the elm platform repo

[Oliver Searle-Barnes]

This caught me out yesterday, I wanted to have a look at the source for 
0.18.0 and was surprised to see that there wasn't a tag for it in github.

On Tuesday, 22 November 2016 11:34:53 UTC+1, futtetennista wrote:
>
> I recently contributed to the docker-elm repo 
>  and in order to build an image for 
> a given elm version the BuildFromSourceFile.hs file is needed 
> . 
> I think it'd be nicer, more explicit and less error-prone to be able to 
> write something like:
>  
>
> https://github.com/elm-lang/elm-platform/blob/0.18/installers/BuildFromSource.hs
>
> instead of using the commit sha but right now new releases are not tagged 
> (the last tag is 0.15) so this is not possible. Would it be possible to add 
> tagging as a mandatory step in the release process in the elm-platform 
> repo? I don't see any reason why this would hurt.
>
> Thanks!
>
>

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

Re: [elm-discuss] Rename Just to Something, as the counterpart to Nothing?

[Oliver Searle-Barnes]

The problem with Some is that it should be A/An/Some depending on the 
subject. I'm starting to come round to Thing vs Nothing. While the grammer 
isn't spot on the semantics are very clear.


On Tuesday, 22 November 2016 11:06:10 UTC+1, Will White wrote:
>
> weapon = Just sword doesn’t make sense for Maybe. It implies “just sword, 
> out of all the weapons”. Just *would* make sense in a Just weapon | All 
> (List weapon) type, where weapon could also be All [ sword, mace, nunchuk 
> ]. 
>
> I think we all agree that Nothing totally nails its concept (better than 
> null for the uninitiated). I'm just looking for a word that implies its 
> alternative is Nothing, e.g. Thing, Something. If it’s grammatically 
> correct, that’s a bonus, but I think eliminating things which hinder 
> understanding is more important.
>
> On 22 Nov 2016, at 00:24, joseph ni <jose...@gmail.com > 
> wrote:
>
> I came to Elm not knowing about the Maybe type. 
> The hardest thing for me to grasp was the use case and being able to map : 
> (a -> b) -> Maybe a -> Maybe b. And knowing when to use a Maybe (rarely) vs 
> when to use a union type or refactor the code so it doesn't need the Maybe 
> type.
>
> If I was to qualitatively estimate the amount of time spent learning about 
> Maybe. I'd say it took me a moment to understand `Maybe a = Just a | 
> Nothing` and a couple of months to get comfortable enough with the Maybe 
> type now to understand where it's needed in my app.
>
> So I'd tend to lean with Joey, the wording works for me and changing it 
> would feel arbitrary and break the current grammatical 'symmetry' as in
> weapon = Just sword 
> vs 
> weapon = Something sword
>
> On Tuesday, 22 November 2016 08:19:21 UTC+11, Oliver Searle-Barnes wrote:
>>
>> I have to admit I did find `Just` very confusing when I first encountered 
>> it, as mentioned earlier in this thread it implies some kind of limitation 
>> which doesn't match the semantics of Maybe at all. That said, it was one of 
>> those little oddities that very quickly become second nature, just wanted 
>> to point out that it is a slight bump in the road for newcomers.
>>
>>
>> On Monday, 21 November 2016 18:34:05 UTC+1, Noah Hall wrote:
>>>
>>> Has anyone actually encountered anyone being confused by the names? I 
>>> haven't. I think this a solution to a problem that doesn't exist. 
>>>
>>> On Mon, Nov 21, 2016 at 6:15 PM, Will White <will.n...@gmail.com> 
>>> wrote: 
>>> > I think that’s because you already know what Just means. I don’t think 
>>> it’s 
>>> > arbitrary though from an accessibility point of view. Some or None is 
>>> easier 
>>> > for newcomers to understand than Just or Nothing, especially as Some 
>>> isn’t 
>>> > misleading the way Just is, as Andrew described well. 
>>> > 
>>> > On 21 Nov 2016, at 17:05, Joey Eremondi <joey.e...@gmail.com> wrote: 
>>> > 
>>> > Honestly, these choices seem pretty arbitrary. Everyone has a 
>>> preference. ML 
>>> > uses Some/None, Haskell uses Just/Nothing. Some people find Something 
>>> > intuitive, some don't. 
>>> > 
>>> > Given that the choices is (mostly) arbitrary, it seems best to stick 
>>> with 
>>> > the status quo. 
>>> > 
>>> > On Mon, Nov 21, 2016 at 7:47 AM, 'Andrew Radford' via Elm Discuss 
>>> > <elm-d...@googlegroups.com> wrote: 
>>> >> 
>>> >> Probably inherited from Haskell, like a lot of other stuff. Doubt if 
>>> there 
>>> >> was any other thought put into it if I'm honest. 
>>> >> 
>>> >> On Monday, 21 November 2016 14:46:40 UTC, Will White wrote: 
>>> >>> 
>>> >>> Sorry, meant to say “I guess he’s already considered and rejected 
>>> them”. 
>>> >>> 
>>> >>> On 21 Nov 2016, at 14:21, Will White <will.n...@gmail.com> wrote: 
>>> >>> 
>>> >>> I prefer Some or None, for understanding. Though, unless Evan didn’t 
>>> know 
>>> >>> about them, I guess we’d already have them. 
>>> >>> 
>>> >>> On 20 Nov 2016, at 23:41, Robin Heggelund Hansen <skinn...@gmail.com> 
>>>
>>> >>> wrote: 
>>> >>> 
>>> >>> How about 'Some' and 'None'? 
>>> >>> Those are not longer to type than what we have today, and they 
>>> should 
>>> >>> solve your initial confusion. 

Re: [elm-discuss] Rename Just to Something, as the counterpart to Nothing?

[Oliver Searle-Barnes]

I have to admit I did find `Just` very confusing when I first encountered 
it, as mentioned earlier in this thread it implies some kind of limitation 
which doesn't match the semantics of Maybe at all. That said, it was one of 
those little oddities that very quickly become second nature, just wanted 
to point out that it is a slight bump in the road for newcomers.


On Monday, 21 November 2016 18:34:05 UTC+1, Noah Hall wrote:
>
> Has anyone actually encountered anyone being confused by the names? I 
> haven't. I think this a solution to a problem that doesn't exist. 
>
> On Mon, Nov 21, 2016 at 6:15 PM, Will White  > wrote: 
> > I think that’s because you already know what Just means. I don’t think 
> it’s 
> > arbitrary though from an accessibility point of view. Some or None is 
> easier 
> > for newcomers to understand than Just or Nothing, especially as Some 
> isn’t 
> > misleading the way Just is, as Andrew described well. 
> > 
> > On 21 Nov 2016, at 17:05, Joey Eremondi  > wrote: 
> > 
> > Honestly, these choices seem pretty arbitrary. Everyone has a 
> preference. ML 
> > uses Some/None, Haskell uses Just/Nothing. Some people find Something 
> > intuitive, some don't. 
> > 
> > Given that the choices is (mostly) arbitrary, it seems best to stick 
> with 
> > the status quo. 
> > 
> > On Mon, Nov 21, 2016 at 7:47 AM, 'Andrew Radford' via Elm Discuss 
> >  wrote: 
> >> 
> >> Probably inherited from Haskell, like a lot of other stuff. Doubt if 
> there 
> >> was any other thought put into it if I'm honest. 
> >> 
> >> On Monday, 21 November 2016 14:46:40 UTC, Will White wrote: 
> >>> 
> >>> Sorry, meant to say “I guess he’s already considered and rejected 
> them”. 
> >>> 
> >>> On 21 Nov 2016, at 14:21, Will White  wrote: 
> >>> 
> >>> I prefer Some or None, for understanding. Though, unless Evan didn’t 
> know 
> >>> about them, I guess we’d already have them. 
> >>> 
> >>> On 20 Nov 2016, at 23:41, Robin Heggelund Hansen  
> >>> wrote: 
> >>> 
> >>> How about 'Some' and 'None'? 
> >>> Those are not longer to type than what we have today, and they should 
> >>> solve your initial confusion. 
> >>> 
> >>> søndag 20. november 2016 18.16.26 UTC+1 skrev Will White følgende: 
>  
>  I'm talking about Maybe.Just, of course. Just has always seemed 
> strange 
>  to me, as if it's hinting that it's something other than just the 
>  counterpart to Nothing. I don't know the reasons behind its naming, 
> but I 
>  think I would prefer Something, as in "something or nothing". What do 
> you 
>  think? 
> >>> 
> >>> 
> >>> -- 
> >>> 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/EHnuE_gGFuo/unsubscribe. 
>
> >>> To unsubscribe from this group and all its topics, send an email to 
> >>> elm-discuss...@googlegroups.com. 
> >>> For more options, visit https://groups.google.com/d/optout. 
> >>> 
> >>> 
> >>> 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "Elm Discuss" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to elm-discuss...@googlegroups.com . 
> >> For more options, visit https://groups.google.com/d/optout. 
> > 
> > 
> > 
> > -- 
> > 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/EHnuE_gGFuo/unsubscribe. 
> > To unsubscribe from this group and all its topics, send an email to 
> > elm-discuss...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Elm Discuss" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to elm-discuss...@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: Is Elm really wrong?

[Oliver Searle-Barnes]

I'm surprised this hasn't come up already, 
http://package.elm-lang.org/packages/eeue56/elm-all-dict/latest

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

Re: [elm-discuss] Re: How do you test a TEA `update` function?

[Oliver Searle-Barnes]

This is an area I've been a little uncomfortable with. There seems two be a 
couple of options though:

1) https://github.com/avh4/elm-testable - I haven't used it but it seems 
that it provides replacement commands that you can run assertions against. 
This approach seems limited as it only solves the problem for a predefined 
set of commands.

2) Another approach, which I also haven't tried yet: Instead of returning 
commands from your update, model the effects yourself and only convert them 
into commands at the last minute when returning them from your main/update. 
For instance you might return MyEffects.request(endpoint, verb, payload, 
GoodResponse, BadResponse). This would allow you to just use assertEquals 
on the effects returned from your update. Something that would need to be 
taken care of though is a replacement for Cmd.map. 




On Monday, 7 November 2016 09:54:53 UTC+1, Simon wrote:
>
> ... which is ironic given all emphasis on 'effects as data'
>
> On Monday, 7 November 2016 09:51:56 UTC+1, Austin Bingham wrote:
>>
>> I asked more or less the same question about a month ago and got no 
>> responses:
>>
>> 
>> https://www.reddit.com/r/elm/comments/593vua/how_to_test_the_complete_update_cycle/
>> https://groups.google.com/d/msg/elm-discuss/634UXiZjRFQ/lVeDED1oBQAJ
>>
>> The only practical answer right now seems to be to use elm-testable, 
>> though I haven't actually tried it myself.
>>
>> This feels like a real blind-spot in the elm ecosystem. The generation 
>> and handling of Cmds is central to a properly functioning app, but there 
>> doesn't seem to be any first-class way to test e.g. Update without driving 
>> the entire app from the top-level. 
>>
>> On Mon, Nov 7, 2016 at 8:28 AM Simon  wrote:
>>
>>> I've often worried about the commands bit.
>>> For the view side, you need to test that you are deriving the right data 
>>> to render, while it is Evan that needs to test that, given certain data, 
>>> expected DOM elements get produced?
>>>
>>>
>>> On Monday, 7 November 2016 07:44:36 UTC+1, Francesco Orsenigo wrote:

 How do you write unit tests to ensure that an `update : Msg -> Model -> 
 ( Model, Cmd Msg )` function is producing the correct commands?
 What if the function is supposed to produce several commands batched 
 together?

 Same thing for a `view : Model -> Html Msg`.
 Suppose I want to test whether, given a particular model, it will 
 display the correct number of list items.
 Do people write tests for this?
 Right now the only way to write this kind of tests I can think of is 
 creating the whole html tree as I expect it to be rendered, and comparing 
 it via == with the function output.

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

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

Re: [elm-discuss] Structure for large Elm apps

[Oliver Searle-Barnes]

@Mark this is a pattern I've been exploring recently. An area that I 
haven't found a solution to is keeping the view model in sync with the 
shared models. For instance, let's say I have a view with a list of 
checkboxes next to each user. The state for the checkboxes would be kept in 
the view model, but then I need to manage adding/removing checkboxes as the 
list of users changes. Currently I handle this by having a default state 
for the checkbox which is used until a user actually clicks on a checkbox 
at which point the state is added to the view model. This works but is 
semantically awkward and doesn't take care of removing the checkbox state 
if a user is removed from the shared list. 
https://github.com/elm-lang/html/issues/19 provides a potential avenue for 
cleanup, but even then the lifecycle seems a little awkward. 

I wonder if you have a different approach for this problem?


On Sunday, 23 October 2016 21:29:23 UTC+2, Mark Hamburg wrote:
>
> We're just getting into having an app where this is likely to matter, but 
> if you have multiple views onto the same data, then the pattern that would 
> seem to apply is to have a single data model and multiple view models. The 
> data model handles the shared part. The view models handle things specific 
> to the particular view — e.g., is a spin down open, what's the scroll 
> position, etc. The view functions would take the data model and their 
> particular view model as parameters and would generate appropriately tagged 
> messages back. This avoids significant nesting while still providing some 
> structure to keep pieces that can be separated separate.
>
> There are then a couple ways to structure the multiple view models. One is 
> to have a view selector but keep all of the view models alive all the time. 
> The benefit of this is that when you switch back to a view, it will 
> remember where you were. The downside is that one is carrying around — and 
> potentially updating if the view model depends on the data model — an 
> increasing number of view models if you have an increasing number of views. 
> The alternative is to put the view models into a union type and have one 
> model entry that serves as both view selector and view model storage. This 
> keeps things lighter weight but means that you have nowhere to maintain 
> context when switching back and forth.
>
> Above all of this, the other key subdivision we are making in our SPA and 
> that I would recommend having seen where other programmers often first 
> head, is having a top layer that handles overall app state — e.g., logged 
> in v not logged in — as a type union. This can also often be where the 
> routing logic plugs in. People who haven't spent a lot of time thinking in 
> terms of type unions tend to load their model up with a lot of fields that 
> only have meaning in certain states. This then leads to more invariants 
> about the state that can't be enforced by the compiler. Breaking things up 
> into different type cases for different states allows one to make more bad 
> states simply impossible. For example, our logging in state has a 
> RemoteData.WebData User reflecting whether we've gotten valid user data 
> back from the server but our logged in state simply has a User. The top 
> level event dispatcher works with the following type signature on the log 
> in state update:
>
> update : Login.Msg -> Login.Model -> ( Login.Model, Cmd Login.Msg, Maybe 
> User )
>
>
> After each call to update, it can check to see whether we now have a valid 
> user and if so switch to the logged in state, initializing it with the 
> supplied user.
>
> This isn't as flat as some people go, but it doesn't spread things out 
> into lots of components and the top layer(s) are pretty simple.
>
> Mark
>
>
> On Sun, Oct 23, 2016 at 11:39 AM, Francois  > wrote:
>
>> Hi,
>>
>> I'm really new to Elm. I'm not good enough to propose a guideline about 
>> Elm app structure but as a novice a guideline can help lots of people.
>>
>> I worked / works on a large angular application and John Papa Styleguide 
>> has been really helpful at the beginning.
>> So writing a community guideline can be a great resource. (there is 
>> another thread inter component that seems related)
>>
>> For example, on the server side, structuring domain core by features is 
>> good thing (for me). Help define some boundaries and help maintability. 
>> Grouping all Java classes by technical aspect at the project root : all 
>> services in one package, all models in one package can be tedious.
>>
>> On the front, if I correctly understood this thread :
>> - a unique Msg / Model inside Main.elm can be a good starting point and 
>> easy to refactor later. 
>> - separating the view per feature (only view functions) : advice taken 
>> from Dave
>> - break Model / Msg when too big (definition of "too big" is perhaps not 
>> easy, or someone can give some advices to detect "a too big Msg"). At this 

[elm-discuss] Re: Another case of functions in the model

[Oliver Searle-Barnes]

Have you had a look at (the currently not 
released) https://github.com/saschatimme/elm-phoenix? Phoenix channels have 
request/response semantics built in which you can use in elm-phoenix via 
Phoenix.push - 
https://github.com/saschatimme/elm-phoenix/blob/master/src/Phoenix.elm#L85. 
See Push.ok for adding a response 
handler 
https://github.com/saschatimme/elm-phoenix/blob/master/src/Phoenix/Push.elm#L69.

On Saturday, 15 October 2016 01:04:32 UTC+2, Mark Hamburg wrote:
>
> We have an app based on making multiple HTTP requests to a server for 
> various pieces of information. All of these requests get implemented as 
> tasks that more or less immediately become commands which then get routed 
> via tagging functions as they flow up through the model. Pretty standard 
> stuff. (I think in 0.18, we get to ignore the task aspect.) 
>
> We're interested in exploring using web sockets or Phoenix channels as an 
> alternative. Now, the request would go upstream on the socket with a tag 
> (probably just a number) and the response would come back down bearing the 
> same tag. 
>
> To keep the same general style of coding as in the HTTP case, it seems 
> like the best implementation would be to use the 
> Requests-as-alternatives-to-Cmds approach. Rather than building a command 
> directly, we would build requests that could be similarly mapped with 
> routing functions as they propagated up through the model from update 
> functions. At the top level, we would maintain a dictionary mapping request 
> ID's to decode-and-route functions and turn the request itself into a 
> command to post to the upstream channel. The listener on the socket would 
> see the responses coming back and look in the dictionary for a 
> corresponding entry. 
>
> That all seems pretty straightforward. But note that the model now 
> contains a dictionary of decode-and-route functions. Is there a solution 
> that avoids this and doesn't gum things up significantly in other ways? 
>
> Mark 
>
>

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

[elm-discuss] Re: Simple Fade In/Out effect?

[Oliver Searle-Barnes]

Another option, which avoids having to add anything to your model, would be

```
crossFadeTextTo text =
  Animation.interrupt
[ Animation.to [Animation.opacity 0]
, Animation.send (DoneFadingOutOldTextPleaseSwitchModelToNewText text)
, Animation.to [Animation.opacity 1]
]
```


On Friday, 30 September 2016 21:01:37 UTC+2, Matthew Griffith wrote:
>
>
> That's a pretty reasonable way to do it.  Another option could be could be 
> to use one div and use `Animation.send`.   Basically you could do something 
> like this.
>
>
> ```
> Animation.interrupt
> [ Animation.to [Animation.opacity 0]
> , Animation.send DoneFadingOutOldTextPleaseSwitchModelToNewText
> , Animation.to [Animation.opacity 1]
> ]
> ```
>
> In this case you'd have to keep new text in a 'staging area' in your model 
> and then switch it in when DoneFadingOutOldTextPleaseSwitchModelToNewText 
> fires.
>
>
> On Friday, September 30, 2016 at 2:30:53 PM UTC-4, Rex van der Spuy wrote:
>>
>> Hi Everyone!
>>
>> Just a quick question: Can anyone suggest a simple way to fade out some 
>> old text and fade in some new text when a `model.text` value changes?
>>
>> I did this once a few apps ago where I created 2 `div` layers: 
>> `currentText` and `previousText`
>> Then, when the text value changed, I moved the text to the previousText 
>> layer and faded it out, and then displayed the updated text on the 
>> currentText layer and faded it in.
>> (I used `elm-html-animation` for the fade effect.)
>>
>> Does this seem reasonable or is there a better, easier way?
>>
>

-- 
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: Json.Decode list of objects without known fields

[Oliver Searle-Barnes]

You can do this with a Dict but it's a little fiddly because you need to 
use an ADT to represent the different types of the values

import Html
import Json.Decode as JD
import Dict
import String


json : String
json =
 """
 [{"a": 1, "foo": "bar", "bar": "baz"},
 {"a": 2, "foo": "baz", "bar": "foo"},
 {"a": 34, "foo": "big", "bar": "lebowski"}]
 """


type ValueType = StringType String | IntType Int


valueTypeDecoder =
  JD.oneOf
[ JD.map StringType JD.string
, JD.map IntType JD.int
]


gen_keys : String -> String
gen_keys json =
json
|> JD.decodeString (JD.list <| JD.dict valueTypeDecoder)
|> Result.toMaybe
|> flip Maybe.andThen List.head
|> Maybe.map Dict.keys
|> Maybe.withDefault []
|> String.join ","


main : Html.Html string
main =
Html.text (gen_keys json)


On Saturday, 17 September 2016 00:52:20 UTC+2, Gary Young wrote:
>
> In short.  Solve this:
>
> module Main exposing (..)
>
> import Html
>
>
> -- import Json.Decode exposing (Decoder, decodeString, keyValuePairs)
>
>
> json : String
> json =
> """[{a: 1, foo: "bar", bar: "baz"},
>  {a: 2, foo: "baz", bar: "foo"},
>  {a: 34, foo: "big", bar: "lebowski"}]"""
>
>
> gen_keys : String -> String
> gen_keys json =
> -- Decode the first JSON record and return a comma separated
> -- list of keys
> json
>
>
> main : Html.Html string
> main =
> Html.text (gen_keys json)
>
>

-- 
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: Syntax suggestion: record property shorthand

[Oliver Searle-Barnes]

While I like the JS style syntax it feels a little early to be optimising 
out line noise. In particular nested updates don't seem entirely resolved 
yet, if new syntax were introduced it would be good to be aware of it when 
deciding whether this optimisation is appropriate.


On Sunday, 11 September 2016 22:37:10 UTC+2, Hyunje Jun wrote:
>
> Hello,
>
> I have uploaded on elm-compiler GH Issues, but I would like to share the 
> idea and gather comments.
>
> https://github.com/elm-lang/elm-compiler/issues/1483
>
> In short, it is about adopting JS-like syntax for objects to Elm records.
>
> { model | foo = foo, bar = bar } -> { model | foo, bar }
>
> I understand adopting a syntax is not an easy decision. Please feel free 
> to leave a comment!
>
> Thanks,
>

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

[elm-discuss] Services (with corrected formatting)

[Oliver Searle-Barnes]

*Apologies for the repost, I missed off the formatting in the original 
post, and as we're using google groups, there's no edit... Hopefully mods 
can delete the original.*


This is following on from the discussion "Private state: A contrived 
example". It was going to be a reply but it got rather long and seems like 
a large enough topic by itself.

I'm currently working on a Store service. It's an abstraction over a 
websocket that provides an API for persisting business models (models that 
are synced with a remote database), things like addFeed, removeUser etc. It 
also handles latency compensation --- changes are applied locally to allow 
immediate UX updates, messages are then sent and confirmed/rejected at the 
server and the local state amended accordingly. This requires that it have 
control over the client state of all models that are stored in the backend 
(so that it can handle switching between optimistic and pessimistic states).

Below I've sketched out some different aspects of the Store service that 
I've been exploring. I've skipped over some of the implementation details 
to focus on the key aspects but if that's left some areas of confusion let 
me know and I'll flesh them out. Also bear in mind that I haven't actually 
implemented this yet so there may be issues that I will hit. It seems a 
good concrete example of a service though so hopefully we can use it to 
flush out some of the architectural issues with services. 



Service commands

Updates in children may want to issue commands to this service, e.g. 
addFeed "feed one". Here's how this might work (it's similar to the 
approach Mark took, folding the commands in with platform commands but with 
platform / service commands separated out).

The service is stored in the root model

mainModel =
  { someViewState
  , services =
{ store
}
  }



commands to be sent to it are returned from update

( model
, Cmd.none
, [Services.storeCmd Store.addFeed "feed one"]
)


Services.storeCmd

returns a constructor that builds an absolute path to the store, so:

Services.storeCmd == ServicesMsg StoreMsg -- absolute path from mainModel


This allows the root update to route the cmd to the Store.

Because each command already contains the absolute path to the service it's 
targeting there's no need for an equivalent to Cmd.batch, they can simply 
be appended.

( model
, Cmd.batch [cmd1, cmd2]
, childServiceCmds ++ [Services.storeMsg Store.addFeed "feed one" ]
)


Information is propagated down the tree from the Store by including the 
required information as a param to the updates e.g.

updateChild msg services.store.feeds childModel


A more generalised version might be

updateChild msg servicesModel childModel



Subscriptions to Store events

I'd like to allow child "components" to subscribe to events like 
FeedDeleted. For instance if a feed view was showing a feed that was 
deleted (perhaps another user deleted the feed and that message has been 
received over the websocket) then rather than show a blank view it would be 
better to switch to a different feed (with a notification at the top so the 
user understands what has happened).

I'm not sure how I'm going to handle this yet. When events are triggered by 
messages received over the websocket then it's a case of mapping higher 
level subscriptions from the child components down to the lower level 
websocket subscriptions. It seems like it might be an appropriate place for 
an effects manager but I've been steered away from those...



Store subscriptions to server

Having written this section I'm now not sure how relevant it is to the 
discussion as it may be specific to the Store, I've included it anyway in 
case it sparks any useful thoughts.

The intention is to allow child "components" to declare the information 
that they need. For instance assume feed viewer component has currentFeedId 
== 3, it wants to request that the Store subscribe to feed 3.

Internally the Store has subscriptions to websocket messages. The 
subscriptions that it registers are based on a storeSubscriptions function 
that sits parallel to the usual subscriptions.

Let's say there's a feed viewer which has it's current feed pointing to 
feed 3. It's storeSubscriptions might look like

storeSubscriptions childModel
  [Store.FeedSubscription childModel.currentFeedId]



and in the parent perhaps you'd have

storeSubscriptions parentModel
  parentStoreSubscriptions ++ (Child.storeSubscriptions parentModel.
childModel)


at the top of the tree the storeSubscriptions are then passed into the 
Store's subscriptions

mainSubscriptions model =
  Store.subscriptions storeSubscriptionsFromAllChildren model.store


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

[Oliver Searle-Barnes]

This is following on from the discussion "Private state: A contrived 
example". It was going to be a reply but it got rather long and seems like 
a large enough topic by itself.

I'm currently working on a Store service. It's an abstraction over a 
websocket that provides an API for persisting business models (models that 
are synced with a remote database), things like addFeed, removeUser etc. It 
also handles latency compensation --- changes are applied locally to allow 
immediate UX updates, messages are then sent and confirmed/rejected at the 
server and the local state amended accordingly. This requires that it have 
control over the client state of all models that are stored in the backend 
(so that it can handle switching between optimistic and pessimistic states).

Below I've sketched out some different aspects of the Store service that 
I've been exploring. I've skipped over some of the implementation details 
to focus on the key aspects but if that's left some areas of confusion let 
me know and I'll flesh them out. Also bear in mind that I haven't actually 
implemented this yet so there may be issues that I will hit. It seems a 
good concrete example of a service though so hopefully we can use it to 
flush out some of the architectural issues with services. 


## Service commands

Updates in children may want to issue commands to this service, e.g. 
addFeed "feed one". Here's how this might work (it's similar to the 
approach Mark took, folding the commands in with platform commands but with 
platform / service commands separated out).

The service is stored in the root model

mainModel =
  { someViewState
  , services =
{ store
}
  }

commands to be sent to it are returned from update

( model
, Cmd.none
, [Services.storeCmd Store.addFeed "feed one"]
)

Services.storeCmd returns a constructor that builds an absolute path to the 
store, so:

Services.storeCmd == ServicesMsg StoreMsg -- absolute path from mainModel

This allows the root update to route the cmd to the Store.

Because each command already contains the absolute path to the service it's 
targeting there's no need for an equivalent to Cmd.batch, they can simply 
be appended.

( model
, Cmd.batch [cmd1, cmd2]
, childServiceCmds ++ [Services.storeMsg Store.addFeed "feed one" ]
)

Information is propagated down the tree from the Store by including the 
required information as a param to the updates e.g.

updateChild msg services.store.feeds childModel

A more generalised version might be

updateChild msg servicesModel childModel


## Subscriptions to Store events

I'd like to allow child "components" to subscribe to events like 
FeedDeleted. For instance if a feed view was showing a feed that was 
deleted (perhaps another user deleted the feed and that message has been 
received over the websocket) then rather than show a blank view it would be 
better to switch to a different feed (with a notification at the top so the 
user understands what has happened).

I'm not sure how I'm going to handle this yet. When events are triggered by 
messages received over the websocket then it's a case of mapping higher 
level subscriptions from the child components down to the lower level 
websocket subscriptions. It seems like it might be an appropriate place for 
an effects manager but I've been steered away from those...


## Store subscriptions to server

Having written this section I'm now not sure how relevant it is to the 
discussion as it may be specific to the Store, I've included it anyway in 
case it sparks any useful thoughts.

The intention is to allow child "components" to declare the information 
that they need. For instance assume feed viewer component has currentFeedId 
== 3, it wants to request that the Store subscribe to feed 3.

Internally the Store has subscriptions to websocket messages. The 
subscriptions that it registers are based on a storeSubscriptions function 
that sits parallel to the usual subscriptions.

Let's say there's a feed viewer which has it's current feed pointing to 
feed 3. It's storeSubscriptions might look like

storeSubscriptions childModel
  [Store.FeedSubscription childModel.currentFeedId]


and in the parent perhaps you'd have

storeSubscriptions parentModel
  parentStoreSubscriptions ++ (Child.storeSubscriptions 
parentModel.childModel)

at the top of the tree the storeSubscriptions are then passed into the 
Store's subscriptions

mainSubscriptions model =
  Store.subscriptions storeSubscriptionsFromAllChildren model.store

-- 
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] Private state: A contrived example

[Oliver Searle-Barnes]

Mark, have you considered the approach that Evan took with elm-autocomplete 
?
 
Personally, I found this a satisfactory approach to the problem of private 
state/events, I'd be interested to hear your take on it.

> From my view, the issue here is with how you scale a page when it is full 
of such "components". 

This is definitely the issue that feels the least resolved for me. The 
elm-parts approach hasn't been endorsed, but I'm not aware of any other 
approach being put forward.


On Saturday, 10 September 2016 16:39:53 UTC+2, Mark Hamburg wrote:
>
> > On Sep 10, 2016, at 1:22 AM, Peter Damoc  
> wrote: 
> > 
> > Charlie was right, an accordion is a better example. 
>
> I'm sure it is. As is a date picker. As with lists of counters as models 
> in the Elm Architecture documents, my example is entirely contrived — 
> hence, my subject line — with the intent that in being so contrived and yet 
> so simple, attention could instead focus on the proposed pattern for 
> handling a combination of public/shared state and private/local state. I 
> figured that these discussions had come around enough that that context 
> would be as clear as the context for why a list of counters is interesting. 
> I seem to have been wrong in that regard. 
>
> > From my view, the issue here is with how you scale a page when it is 
> full of such "components". 
>
> I rather hoped that if the approach I took could be endorsed as being 
> closer to what some would argue is the right way to write Elm code that the 
> scalability issue could be the next discussion point. But to get there we 
> need something that's being scaled and we can't even seem to get to that 
> point. 
>
> Mark 
>
>

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

Re: [elm-discuss] Feature proposal: Html.none

[Oliver Searle-Barnes]

This is something that comes up a lot in the #beginners channel. After 
seeing Cmd.none and Sub.none people instinctively reach for Html.none for 
conditionally rendered parts of the view and are surprised when it doesn't 
exist. 

Using `text ""` is a great practical solution but Html.none is clearer and 
allows the VDOM to avoid adding the extra text node.


On Thursday, 1 September 2016 01:16:30 UTC+2, Nick H wrote:
>
> Evan pointed out on Elm Dev that this is functionality is already 
> available:
>
> none = text ""
>
> but I don't think that solution is very obvious, and agree that adding 
> none to the library would be nice. 
>
> On Wed, Aug 31, 2016 at 4:02 PM, Mark Hamburg  > wrote:
>
>> Html.none would produce a virtual DOM node but that node would not 
>> produce anything in the actual DOM. It's usage is an alternative to list 
>> concatenation and empty divs. For example:
>>
>> div []
>> [ headerView model,
>> , model.error |> Maybe.map errorBoxView |> Maybe.withDefault Html.none
>> , bodyView model
>> ]
>>
>> Now, when diffing the virtual DOM, the header, optional error box, and 
>> body are always at the same indices within the div but we haven't cluttered 
>> the real DOM with empty nodes.
>>
>> Mark
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [elm-discuss] Installing packages direct from github

[Oliver Searle-Barnes]

Ah, good to know. A note in the readme would be good.

On Friday, 19 August 2016 14:56:19 UTC+2, Janis Voigtländer wrote:
>
> Aside: For the specific case of 
> https://github.com/circuithub/elm-maybe-extra, you might more easily have 
> switched to https://github.com/elm-community/maybe-extra, which is 
> maintained, is being kept up to date with Elm compiler releases, and is the 
> “official successor” of circuithub/elm-maybe-extra (with circuithub‘s 
> blessing, as you can see here 
> <https://github.com/elm-community/maybe-extra/commit/f9db6f43c6b078b95bd98e34a0dfb4f721489407>
> ).
> ​
>
> 2016-08-19 14:37 GMT+02:00 Oliver Searle-Barnes <oli...@opsb.co.uk 
> >:
>
>> I've recently started using 
>> https://github.com/gdotdesign/elm-github-install in place of the usual 
>> package manager. It allows you to install dependencies direct from github 
>> whilst still handling the semantic versioning resolution.
>>
>> Here are some scenarios where this is really helpful
>>
>> 1) Fixing bugs - if I use someone else's library and find a bug in it 
>> then most likely it's far more important to me that it's fixed than it is 
>> for them. If I can install the dependency from github then I can simply 
>> fork it and use my fork until the PR has been merged in. If I have an app 
>> in production this is absolutely essential, the only alternative is to 
>> copy/paste the code into my project and apply a fix there which seems a 
>> poorer solution in every way.
>>
>> 2) Applying updates - similar to (1) if I use someone else's library and 
>> I need to update it for elm 0.17 for instance then I can just fork it and 
>> apply the changes. 
>>
>> 3) Using dependencies that rely on native code - I'm aware of the 
>> argument that native code should be discouraged as far as possible and that 
>> this would make it too easy to reach for native code where an Elm solution 
>> would be better. My counter argument would be that the community is 
>> currently small but full of people who are trying to encourage adoption of 
>> Elm at their workplace. Elm becomes a much harder sell if you can't rely on 
>> existing javascript solutions when necessary. I think it's right that 
>> packages with native code are kept out of http://package.elm-lang.org/, 
>> this sends a strong signal that pure Elm solutions are very much preferred. 
>> The community already has the notion that javascript code should be 
>> considered "unsafe" so I feel confident that there would be a trend towards 
>> pure Elm solutions over time.
>>
>> To give you two concrete examples where I've already found this really 
>> useful:
>>
>> https://github.com/zapnito/local-storage - a fork of 
>> https://github.com/elm-lang/local-storage, while this is a draft it's a 
>> practical implementation written by the author of Elm (thanks Evan!) and 
>> it's highly unlikely that I'm going to improve on it. By using it I'm 
>> accepting a degree of risk, changing signatures, unexpected behaviour etc. 
>> but it still seems far more preferable to the other options.
>>
>> https://github.com/zapnito/elm-maybe-extra - a fork of 
>> https://github.com/circuithub/elm-maybe-extra, it has seem really handy 
>> functions that I wanted to use but it hadn't been updated for Elm 0.17, it 
>> took a couple of minutes to fork it, update the dependencies, change a 
>> `package` statement and have it installed in my project ready to go.
>>
>> It would be great to see official support for these workflows. I think it 
>> would help adoption (as a developer intending to put an Elm in production 
>> it gives me a lot more confidence that I can solve any issues I come across 
>> without depending on 3rd parties) without harming the "gold standard" of 
>> the packages at package.elm-lang.org.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[elm-discuss] Installing packages direct from github

[Oliver Searle-Barnes]

I've recently started 
using https://github.com/gdotdesign/elm-github-install in place of the 
usual package manager. It allows you to install dependencies direct from 
github whilst still handling the semantic versioning resolution.

Here are some scenarios where this is really helpful

1) Fixing bugs - if I use someone else's library and find a bug in it then 
most likely it's far more important to me that it's fixed than it is for 
them. If I can install the dependency from github then I can simply fork it 
and use my fork until the PR has been merged in. If I have an app in 
production this is absolutely essential, the only alternative is to 
copy/paste the code into my project and apply a fix there which seems a 
poorer solution in every way.

2) Applying updates - similar to (1) if I use someone else's library and I 
need to update it for elm 0.17 for instance then I can just fork it and 
apply the changes. 

3) Using dependencies that rely on native code - I'm aware of the argument 
that native code should be discouraged as far as possible and that this 
would make it too easy to reach for native code where an Elm solution would 
be better. My counter argument would be that the community is currently 
small but full of people who are trying to encourage adoption of Elm at 
their workplace. Elm becomes a much harder sell if you can't rely on 
existing javascript solutions when necessary. I think it's right that 
packages with native code are kept out of http://package.elm-lang.org/, 
this sends a strong signal that pure Elm solutions are very much preferred. 
The community already has the notion that javascript code should be 
considered "unsafe" so I feel confident that there would be a trend towards 
pure Elm solutions over time.

To give you two concrete examples where I've already found this really 
useful:

https://github.com/zapnito/local-storage - a fork of 
https://github.com/elm-lang/local-storage, while this is a draft it's a 
practical implementation written by the author of Elm (thanks Evan!) and 
it's highly unlikely that I'm going to improve on it. By using it I'm 
accepting a degree of risk, changing signatures, unexpected behaviour etc. 
but it still seems far more preferable to the other options.

https://github.com/zapnito/elm-maybe-extra - a fork 
of https://github.com/circuithub/elm-maybe-extra, it has seem really handy 
functions that I wanted to use but it hadn't been updated for Elm 0.17, it 
took a couple of minutes to fork it, update the dependencies, change a 
`package` statement and have it installed in my project ready to go.

It would be great to see official support for these workflows. I think it 
would help adoption (as a developer intending to put an Elm in production 
it gives me a lot more confidence that I can solve any issues I come across 
without depending on 3rd parties) without harming the "gold standard" of 
the packages at package.elm-lang.org.

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

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

[Oliver Searle-Barnes]

Thanks Richard and Erik for your input, I am taking this all onboard and 
giving it lots of thought. I think the next step for me is to experiment 
and refactor my app into a couple of different structures. That should give 
me a feel for what works well and what doesn't. Thanks again.


On Thursday, 18 August 2016 01:33:15 UTC+2, Richard Feldman wrote:
>
>
>
> If you mean dividing a component into 3 separate files - ie. model.elm, 
>> update.elm, view.elm , then yeah, that's fine. A single file is too. If you 
>> have a massive Elm component that you feel is difficult to manage in a 
>> single file, and splitting it into three pieces will make it much easier to 
>> maintain and understand, go ahead and do that. Whether your component is 3 
>> files, or a single file shouldn't change your overall architecture - it's 
>> just a horizontal partitioning of functions.
>>
>
> Totally agree! I tried to present this advice on another thread 
>  
> but I'm not sure I said it as well as you just did. ;D
>  
>
>> I'm not sure what you mean by framework - do you mean elm-parts? If so, 
>> just forget about that for now and connect your components manually. It's 
>> not a big deal.
>>
>
> 100% agree.
>  
>
>> as the SPA transitions from page to page, we load only the data that is 
>> required for that page - We have no central business data in our app, 
>> because our server itself serves acts as the single source of truth.
>>
>
> +1 to this too
>
> If you're using websockets to update your business model, go ahead and do 
>>> that - the model will be automatically reflected in the view. *Your 
>>> view shouldn't know anything about websockets.*
>>>
>>
> Strongly agree! Only update should know or care that websockets are 
> involved.
>
> I would second the need for better "official" documentation in Elm for 
>> folks getting started. There is a learning curve to Elm, but once it 
>> "clicks", it'll be more obvious how to piece your application together.
>>
>
> I think part of the challenge is figuring out where the gaps are. Threads 
> like this are super helpful in surfacing specific questions, so HUGE thanks 
> to Oliver for posting it!
>

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

Re: [elm-discuss] Re: Elm UI boilerplate

[Oliver Searle-Barnes]

In my experience every large SPA I've worked on has ended up building a set 
of it's own components similar to elm-mdl. They've usually been used 
alongside other components that have been provided by libraries such as 
elm-mdl but they're still a significant part of the codebase. From this 
perspective, and judging by the questions I've seen in slack, this is 
something that pretty much every Elm developer is going to need to resolve. 

It would also be great to have a healthy selection of UX components 
available at http://package.elm-lang.org/. To get a concrete idea of some 
of the sorts of components this might be take a look 
at https://emberobserver.com/categories/components. 

Making it easy to author, share and consume UX components will only make 
building Elm apps even more pleasurable :) I'd caution against treating it 
as a special case for advanced use or the select few. 


On Thursday, 18 August 2016 08:25:29 UTC+2, Peter Damoc wrote:
>
> A small clarification that came up in an earlier discussion. 
>
> This is a boilerplate example for the case where you have many small 
> components that are unavoidably stateful as it is the case with UI 
> toolkits. 
>
> This is a topic that concerns very few people from an implementation point 
> of view but stands to concern a lot of people from usage point of view. 
>
> Most of the components needs are covered by current technologies. 
>
> One more thing that might be worth mentioning: 
> Adding a new field involves changing the code in 3 places for the 
> with-parts version and it 5 places for the without-parts code. 
>
>
> P.S. Many thanks to Josh for cleaning up the code of without-parts 
> example.  
>
> -- 
> 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] We need a clearer story on architecture

[Oliver Searle-Barnes]

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

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

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

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


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

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

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

[Oliver Searle-Barnes]

Thanks, this is really practical advice.


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

1) reusabled UI components

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

2) services 

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

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

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

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

 

>
>

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