[elm-discuss] Re: Seeking feedback: CSS Modules in Elm

[Eirik Sletteberg]

It would be great to be able to distinguish between local and global CSS 
classes, with the :local and :global syntax from CSS modules. That's 
possible with Webpack today; any CSS class marked :local will be hashed. 
(Using style-loader + css-loader + postcss-loader)

tirsdag 6. juni 2017 04.00.06 UTC+2 skrev Kevin Yank følgende:
>
> Neat project, thanks for sharing Marek!
>
> CSS Modules, of course, have additional features such as the ability to 
> include unique hashes in class names and IDs (so that you can have two CSS 
> modules with the same name, both containing identically-named classes, and 
> have them still not conflict with each other), as well as the ability to 
> compose classes within and between CSS modules. I do appreciate the 
> stack-independence that your solution provides, however!
>
> On Monday, June 5, 2017 at 5:28:52 AM UTC+10, Marek Fajkus wrote:
>>
>> Interesting project!
>>
>> We had this problem too but have decided we don't want to lock us to 
>> webpack so much (even though we're currently using it). If you're 
>> interested you can have a look at 
>> http://package.elm-lang.org/packages/GlobalWebIndex/class-namespaces/latest. 
>> Simply we're just generating class selectors using this lib in elm and 
>> corresponding selectors using scss to generate everything on style's side.
>>
>> Anyway I'm looking forward to play with your plugin as well if I'll find 
>> time do so 
>>
>

-- 
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: Best practices to create examples for an elm package?

[Eirik Sletteberg]

Maybe write an example in the form of an integration test - then you know your 
example will be up to date with the actual code, and it may even discover bugs!

-- 
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: Moving on

[Eirik Sletteberg]

That only depends on your definition of good tool vs. bad tool. You're 
painting a doomsday picture here. In the context of real world usage and 
mainstream adoption, it isn't so black and white. Java is a hugely popular 
language, but it has fundamental flaws, like nullable values. Yet there are 
so many great things that have been built with Java/C++/insert 
language/technology here. It was certainly a huge step forward from what 
was before, C/C++/insert language/technology here. People thought nulls 
were good it the time they designed Java. Later on, we learned that there 
were better ways to do things. That's the way technology evolves. You 
cannot take tools back, but you can give people new tools. If the bad tools 
aren't widely replaced with the new tools, then maybe the bad tools weren't 
so bad after all, or at least they were good *enough*.

Even Elm will make fundamental design flaws that we aren't aware of, and 
won't be aware of until we learn from them. Nothing lasts forever; even Elm 
will one day be obsolete, which is a good thing, because then we will have 
another, even greater language/technology, based on lessons learnt from 
Elm! Who knows, maybe that new language promises Elm interop, to benefit 
from the large Elm community/ecosystem, just like Elm promises JS interop 
today.

People were discussing Elm 1.0 more than 3 years ago, and it hasn't 
happened yet. I think there's a general fear of release number 1.0 in the 
open source community at large. But even if Elm 1.0 is released, with its 
inevitable design mistakes, that doesn't mean the end of Elm. (nulls 
weren't the end of Java either). It will always be possible to release Elm 
2.0. At least I hope the ecosystem opens up soon, I would be sorry to see a 
great project like Elm suffer from Perfectionist's Dilemma, never accepting 
the risks of an open ecosystem, and never achieve broad adoption.

onsdag 26. april 2017 22.00.53 UTC+2 skrev Joey Eremondi følgende:
>
> There is an underlying premise of Elm that there is One Correct Way™ to 
>> solve a problem in an application written in Elm, it takes "a long time" to 
>> discover the One Correct Way™, and Evan is the only person capable of 
>> doing it.
>
>
> It's not that there's one way of doing it, but that once a bad way of 
> doing it is widespread, it never dies. Once you give people a tool, you can 
> never take it back, even if it is a bad tool. The goal is to make Elm solid 
> *before* 1.0, so that after 1.0, we won't be plagued by backwards 
> compatibility issues. 
>
> On Wed, Apr 26, 2017 at 12:57 PM, Eirik Sletteberg <eiriksl...@gmail.com 
> > wrote:
>
>> I used the persistent-cache code once. I just copied the source code into 
>> my project. The library readme makes some bold statements, like "it is the 
>> right technical choice" to expose a LRU cache for localStorage in Elm. It 
>> certainly wasn't the right choice for my use case, where "least recently 
>> used" wasn't a relevant factor regarding which elements to retain in 
>> localStorage; there were a few very important keys, and a couple of "less 
>> important" keys. The Task-based LocalStorage API that is included in 
>> persistent-cache works very well. It works very well because it mirrors the 
>> native API. As a developer, I also prefer the freedom to make my own 
>> technical choices that are right given the circumstances. I need the power 
>> of the Web API, I just want it with types and without runtime exceptions.
>>
>> There is an underlying premise of Elm that there is One Correct Way™ to 
>> solve a problem in an application written in Elm, it takes "a long time" to 
>> discover the One Correct Way™, and Evan is the only person capable of 
>> doing it. (An exaggeration of course) As far as web APIs are concerned, 
>> there is only one Correct Way™ we all have to deal with, which is W3C 
>> standards, as they are implemented in the browsers. Maybe it's possible to 
>> take WebIDL definitions and convert them to Elm bindings, then one would 
>> have a type-safe, exception-free interface to the browsers, without all the 
>> maintenance overhead.
>>
>> BDFL for both a language and its ecosystem is perfectly fine for a 
>> project philosophy, but it is intrinsically linked to having a small niche 
>> community. Then again, broad adoption may not be a significant priority for 
>> Elm during the next few years, so that might be a good thing. In the case 
>> of commercial software development, cash is king, and delivering working 
>> features is the top priority. Nobody cares that your car is shiny and 
>> polished, if it cannot drive in reverse. The article Choose Boring 
>> Technology <http://mcfunley.com/c

Re: [elm-discuss] Re: Moving on

[Eirik Sletteberg]

I used the persistent-cache code once. I just copied the source code into 
my project. The library readme makes some bold statements, like "it is the 
right technical choice" to expose a LRU cache for localStorage in Elm. It 
certainly wasn't the right choice for my use case, where "least recently 
used" wasn't a relevant factor regarding which elements to retain in 
localStorage; there were a few very important keys, and a couple of "less 
important" keys. The Task-based LocalStorage API that is included in 
persistent-cache works very well. It works very well because it mirrors the 
native API. As a developer, I also prefer the freedom to make my own 
technical choices that are right given the circumstances. I need the power 
of the Web API, I just want it with types and without runtime exceptions.

There is an underlying premise of Elm that there is One Correct Way™ to 
solve a problem in an application written in Elm, it takes "a long time" to 
discover the One Correct Way™, and Evan is the only person capable of doing 
it. (An exaggeration of course) As far as web APIs are concerned, there is 
only one Correct Way™ we all have to deal with, which is W3C standards, as 
they are implemented in the browsers. Maybe it's possible to take WebIDL 
definitions and convert them to Elm bindings, then one would have a 
type-safe, exception-free interface to the browsers, without all the 
maintenance overhead.

BDFL for both a language and its ecosystem is perfectly fine for a project 
philosophy, but it is intrinsically linked to having a small niche 
community. Then again, broad adoption may not be a significant priority for 
Elm during the next few years, so that might be a good thing. In the case 
of commercial software development, cash is king, and delivering working 
features is the top priority. Nobody cares that your car is shiny and 
polished, if it cannot drive in reverse. The article Choose Boring 
Technology  comes to mind.

Bottom line, there is a huge untapped potential here, people are excited 
about Elm, want to use it in production, but then there are small things 
like missing support for localStorage, file uploads, audio playback, binary 
data, being able to control event.preventDefault(). Many of those are 
problems that people would fix themselves and publish as a package. All it 
takes is to trust the broader community. Even if you end up with 5 
different libraries dealing with cookies, one of them will probably 
prevail, and all 5 of them will learn from each other's advantages and 
drawbacks. I don't buy the argument that opening up the ecosystem will ruin 
Elm's guarantees - I would trust the robustness of a third party cookie 
package with 5000 GitHub stars and 100 merged pull requests just as much as 
(or more than) I trust the Elm core. Just look at what npm did for the 
JavaScript community. Look at the success of React and Redux, which are 
more or less based on TEA. But they have excellent JS interop and an open 
ecosystem. Wouldn't it be great if Elm were just as widespread? And had 
just as many contributors?


onsdag 26. april 2017 19.28.59 UTC+2 skrev Wojtek Piekutowski følgende:
>
> The thing is that this exact kind of cache (LRU) might not work for all 
> people, so it'd be great to have barebones interface to 
> localStorage/sessionStorage/etc. Then higher level abstractions, like 
> persistent-cache, could be easily built on top of it.
>
> On Wed, 26 Apr 2017 at 18:24, Mark Hamburg  > wrote:
>
>> Exactly and look at the months old comment at the top of the read me:
>>
>> NOT RELEASED YET — I hope to release it relatively soon, but I cannot 
>> make any promises. Until then, please use ports if you want to use 
>> localStorage.
>>
>>
>> On Wed, Apr 26, 2017 at 9:22 AM Rex van der Spuy > > wrote:
>>
>>> On Wednesday, April 26, 2017 at 5:07:39 AM UTC-4, Wojtek Piekutowski 
>>> wrote:


  https://github.com/elm-lang/persistent-cache?

>>>
>>>  Wow, that's exactly what I need!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>>
>>>
>>> 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...@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, 

Re: [elm-discuss] Re: elmvm (Elm Version Manager)

[Eirik Sletteberg]

None of these tools are mentioned in the Elm documentation. It only points to 
installers and the npm module.

-- 
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] elmvm (Elm Version Manager)

[Eirik Sletteberg]

https://github.com/eirslett/elmvm

This is a simple utility inspired by nvm (Node Version Manager).
It lets you install and manage multiple versions of Elm on the same 
machine, and switch between them easily.

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

[elm-discuss] Re: elm debugger as a browser extension

[Eirik Sletteberg]

Looks good, that's what I was looking for!

fredag 24. mars 2017 23.26.41 UTC+1 skrev Roman Frołow følgende:
>
> Have you seen this? https://github.com/jinjor/elm-devtool
>
> --
> Roman
>

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

[elm-discuss] elm debugger as a browser extension

[Eirik Sletteberg]

It would be nice to have the elm debugger (the overlay one you get when 
running apps with elm-reactor) as a browser extension, instead of being 
embedded in the document. Something like the 
redux-devtools-extension: https://github.com/zalmoxisus/redux-devtools-extension
How would one approach solving such a problem?
Is it possible to make the elm compiler output debug hooks that a browser 
extension can hook into? And then the debugger could simply be rendered in 
a browser extension?

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

[elm-discuss] Re: How do you handle dependencies between updaters?

[Eirik Sletteberg]

That was what I was thinking, put all the application state in one model, 
and all updaters will deal with that single model, instead of each Updater 
having its own sub-model. In the end, almost all the data is dependent 
somehow.

tirsdag 21. mars 2017 12.22.15 UTC+1 skrev Fedor Nezhivoi følgende:
>
> > for example the User Profile model might need data from the Session model
>
> This is probably the biggest issue with how people used to do it in Redux. 
> If you read it closely then you'll see that your data is dependent. By 
> separating it between modules you do not make it in decoupled, you just 
> create more boilerplate and complexity in how it works together. This was 
> one of the reasons Redux discarded `waitFor` mechanism from Flux. If you 
> have dependent data just put it in one reducer, that's it. I guess this 
> pretty much applies here for Elm as well.
>

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

[elm-discuss] Re: How do you handle dependencies between updaters?

[Eirik Sletteberg]

Is it an option to make all the updaters deal with the root model and the 
root message?
And in the "main" updater, just compose the other updaters?
It could make things simpler, but hurt isolation. Also I'm not sure whether 
that would introduce circular dependencies between modules?

mandag 20. mars 2017 12.58.38 UTC+1 skrev Eirik Sletteberg følgende:
>
> In larger Elm apps, it makes sense to divide Updaters so you can 
> package-by-feature.
> For example, a single page application could have updaters like this:
>
> - Configuration updater
> - Session updater
> - User Profile updater
> - User Settings updater
> - Content updater
> - Some other business specific updater
>
> The challenge is when there are dependencies between Updaters, for example 
> the User Profile model might need data from the Session model, the Session 
> updater might need to send messages to the User updater (Load user profile 
> when session is updated), or the Content updater may need to check for the 
> Session updater (get session ID to send as parameter to the API when 
> fetching content), or some business-specific updater may need to interact 
> with both the Content updater, the User updater, and the Configuration 
> updater.
>
> In Redux, one would use combineReducers to mount each reducer under its 
> own path, and then one can trigger actions across reducers. How would you 
> solve this 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.

[elm-discuss] How do you handle dependencies between updaters?

[Eirik Sletteberg]

In larger Elm apps, it makes sense to divide Updaters so you can 
package-by-feature.
For example, a single page application could have updaters like this:

- Configuration updater
- Session updater
- User Profile updater
- User Settings updater
- Content updater
- Some other business specific updater

The challenge is when there are dependencies between Updaters, for example 
the User Profile model might need data from the Session model, the Session 
updater might need to send messages to the User updater (Load user profile 
when session is updated), or the Content updater may need to check for the 
Session updater (get session ID to send as parameter to the API when 
fetching content), or some business-specific updater may need to interact 
with both the Content updater, the User updater, and the Configuration 
updater.

In Redux, one would use combineReducers to mount each reducer under its own 
path, and then one can trigger actions across reducers. How would you solve 
this 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.

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

[Eirik Sletteberg]

It's easy to find concrete issues - a whole class of issues would be solved 
with task ports.
All problems that require interop between Elm and JS, where a message from 
Elm to JS must be correlated with a message from JS to Elm. The async 
request-response pattern. Like callbacks or Promises in JS land.

- Interacting with new web APIs that are not yet supported by Elm:
- IndexedDB, LocalStorage, SessionStorage
- Messages to/from Web Workers and Service Workers
- Sending two messages to the same outgoing port, receiving two responses 
on an incoming port, the responses may come out-of-order, correlating which 
response belongs to which outgoing message

With task ports, one can write less JS, more generalised, and then build 
business logic in Elm on top of that generic JS code. With the standard 
setup today, workarounds will generally involve more business logic on the 
JS side. Instead of using the elm-xxx library for example, for web API xxx 
(localstorage for example, where Elm development has stalled), users can 
make their own ad-hoc bridge, get Tasks on the Elm side, and compose these 
Tasks into more complicated Tasks. Where most of the complexity ends up in 
Elm, and as little as possible in JS.


onsdag 24. august 2016 00.21.38 UTC+2 skrev Tim Stewart følgende:
>
>
> I know, Elm design decisions are based on concrete use cases not on waffly 
> hand-waving. I'll try and find time to write one up.
>
>>
>>>  

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

[Eirik Sletteberg]

I think this would be a very useful feature!
I forked the Elm compiler and made a working proof of 
concept: https://github.com/eirslett/elm-task-port-example
Is this still something people think would be a good idea?


lørdag 13. august 2016 17.31.07 UTC+2 skrev James Wilson følgende:
>
> The problem
>
> ports as they stand are fundamentally incompatible with Tasks. Being 
> backed by Cmd's, they are harder to compose. A frustration of mine is that 
> often we are directed to "just use ports" when a proper interface to some 
> native API is not yet available, but this leads to our Msg types growing 
> and more significant changes being required when eventually the proper 
> interface is made available.
>
> Also, many JS interop things I find myself wanting to do are fundamentally 
> one-shot functions which I expect a result back into Elm from immediately, 
> or otherwise just want to compose with other Task based things. Some 
> examples that come to mind of one-shot tasks you may want to compose rather 
> than use the streaming interface that ports provide:
>
>- Getting items from local/sessionStorage
>- .. really, most things involving working with the Web API that arent 
>yet implemented in Elm.
>- Embedding JS widgets into Elm elements
>- Using a JS library for doing things like hashing passwords or 
>obtaining some data back from some custom service
>- Interacting with things like Electron for creating apps that can run 
>in the desktop and interact with the filesystem etc.
>
>
> The solution
>
> Task ports. The idea is that these are defined the same way that Ports in 
> elm currently are, but they return a Task type rather than a Cmd or Sub 
> type. On the JS Side, we attach a function to the Elm app that returns a 
> Promise, and on the Elm side we wait for the Promise returned to reject or 
> resolve, and marhsall the error or result from the promise into the error 
> or result type required by the Task type of the port.
>
> Let's see how this might work:
>
>
> *Ports.elm:*
>
> port apiSession: Task String SessionId
>
>
>
> *Main.elm:*
>
> import Ports
> import Json.Decode as Decode
> import Task exposing (andThen)
>
>
> -- get an API session from JS land and make an http request using it
> -- given some path and a decoder to decipher the result:
> apiRequest : String -> Decoder a -> Task ApiError a
> apiRequest path decoder =
>   let
> headers sessId =
> [ ("Content-Type", "application/json")
> , ("MyApp-SessionId", sessId)
> ]
>
>
> req sessId = Http.send Http.defaultSettings
> { verb = "POST"
> , headers = headers sessId
> , url = path
> }
>
>
> decodeResponse res = Decode.decodeString decoder -- ...handle error 
> etc
>   in
> Ports.apiSession `andThen` req `andThen` decodeResponse
>
>
> *App.js:*
>
> Elm.Main.ports.apiSession = function(){
> return new Promise(function(resolve,reject){
>
>
> var sess = localStorage.getItem("sessionId");
> if(!sess) reject("NO_SESSION");
> else resolve(sess);
>
>
> });
> }
>
> var app = Elm.Main.fullscreen();
>
>
>
>
> Here, we use a tiny bit of JS to access localStorage and pull out a 
> session ID. This function is used whenever the apiRequest Task is performed 
> in Elm, and composes nicely into our apiRequest without the need for a 
> complicated effect manager or threading a sessionId through everywhere just 
> because we need to get it from a Cmd based port.
>
> One of the nice things about this is that there is minimal refactoring to 
> do for those things that do eventually receive coverage in the Elm Web API 
> - you're just swapping out Tasks for other Tasks. As the Web API will 
> always be changing, I think that having a nice way to make JS polyfills 
> like this will always have some value, let alone for interacting with 
> libraries written in JS that haven't or won't ever be ported to Elm.
>
> Elm would continue to make the same guarantees as with other ports; if the 
> task port can't marshall the response back into Elm an error would be 
> thrown along the same lines as is currently done via ports.
>
> Summary
>
> - regular ports only let you send data off or receive data back, not both.
> - Cmd's and Sub's are not composable
> - Task based ports allow you to create a new Task that is backed by JS
> - Task based ports allow for better composition and less friction when the 
> backing JS is eventually implemented in Elm.
>
> I'd love to hear what people think about this. Perhaps I'm missing some 
> big issues with the idea for instance, or maybe it's an awesome idea :) 
> What do you all think?
>
>

-- 
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] Multiple views sharing the same state?

[Eirik Sletteberg]

Yes, flags works on startup, but it won't work so well after incremental 
updates, will it?

I guess ports is an option (unless you use union types, which makes that 
hard, see the other thread) but I'm a bit concerned about the performance 
overhead of that. With N components the state has to first be serialized to 
JSON once, and then deserialized from JSON to Elm data structure N times. 
Preferably one wouldn't have to go into JS land and back for this to work?

fredag 3. mars 2017 16.37.34 UTC+1 skrev Peter Damoc følgende:
>
> You can pass the common information to the individual Elm components as 
> flags. 
> You could also wire the components by connecting their ports in such a way 
> that one component could push state and that state be sent to the rest of 
> the components. 
>
> On Fri, Mar 3, 2017 at 3:56 PM, Eirik Sletteberg <eiriksl...@gmail.com 
> > wrote:
>
>> Another use case for a migration from JS app to Elm app; You rewrite one 
>> view JS -> Elm, and then another view, and so on, and then some components 
>> on the page are JS views, some are Elm views. But if there is state in Elm, 
>> it would be desirable for all the views to share the same state (for 
>> example session/user state). Is that possible?
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>

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

Re: [elm-discuss] Re: Sending tagged unions through ports

[Eirik Sletteberg]

That looks a bit clumsy to use from JS land though... if you want to read 
numberOfDoors you'll have to loop through all the fields to find the 
correct one? The format has to be both correct and easy to work with.

fredag 3. mars 2017 19.42.52 UTC+1 skrev Rupert Smith følgende:
>
> On Friday, March 3, 2017 at 4:35:00 PM UTC, Eirik Sletteberg wrote:
>>
>> type alias Car =
>>   { numberOfDoors: Int
>>   }
>>
>> type alias Plane =
>>   { maxSpeed: Int
>>   }
>>
>> type Transport = Walk
>>   | Ride Car
>>   | Fly Plane
>>
>
> Or could be mapped to something that can be described with a json-schema 
> enum for each 'tag' in the union type:
>
> { _type: "Walk" }
>
> { _type: "Ride"
> , fields : [ {numberOfDoors: 1} ]
> }
>
> { _type: "Fly"
> , fields: [ { maxSpeed: 100 } ]
> }
>
> Where 'fields' is a list of the constructor arguments. Would be nice if I 
> could always find a 1:1 mapping between the Elm type and a json-schema.
>
>
>

-- 
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: Sending tagged unions through ports

[Eirik Sletteberg]

type alias Car =
  { numberOfDoors: Int
  }

type alias Plane =
  { maxSpeed: Int
  }

type Transport = Walk
  | Ride Car
  | Fly Plane

Could be encoded as [name, encoded] or just [name] if it's only an 
identifier without a value.
So they would be encoded as

['Walk']

or

['Ride', {
  numberOfDoors: 4
}]

or ['Fly', {
  maxSpeed: 1000
}]

fredag 3. mars 2017 17.18.02 UTC+1 skrev Rupert Smith følgende:
>
> On Friday, March 3, 2017 at 3:29:34 PM UTC, Peter Damoc wrote:
>>
>> It makes sense to focus on other issues that are more important BUT, 
>> people are having enough troubles with boilerplate introduced by decoders 
>> that this could easily be considered a priority. 
>>
>
> +1 from me, just for the convenience of being able to do it.
>
> What would the default mapping for a union type to json looks like? 
>

-- 
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] Multiple views sharing the same state?

[Eirik Sletteberg]

Another use case for a migration from JS app to Elm app; You rewrite one 
view JS -> Elm, and then another view, and so on, and then some components 
on the page are JS views, some are Elm views. But if there is state in Elm, 
it would be desirable for all the views to share the same state (for 
example session/user state). Is that possible?

-- 
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] Sending tagged unions through ports

[Eirik Sletteberg]

An example use case for this would be when gradually porting an existing 
Redux-based app to Elm.
One could rewrite state handling from Redux into Elm updaters/messages, and 
wrap the Elm app's main updater, so that after every message is passed 
through the updater, it sends the whole state tree through a port, which 
would then be picked up by the legacy application's view (it could consist 
of React components, for example).
Or one could imagine mapping the state into multiple "ViewModel" objects, 
and dispatch them to different ports (one port per ViewModel type?) but 
whenever you try to send a tagged union type, there's no support for that 
yet.

-- 
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] Ports and Tasks

[Eirik Sletteberg]

I'm trying to build a userland interface for localStorage:

-- Send in key
port storageGetItem : String -> Cmd msg

-- Returns key + Just value if it exists, Nothing if it doesn't. I guess it 
could also return just the value.
port storageGetItemResult : ((String, Maybe String) -> msg) -> Sub msg


Even though localStorage has synchronous operations in the browser,

that's an implementation detail, I want to be able to design code where the

implementation could be async (IndexedDB for example).


Is there a way I can turn this into a Task? So I could to


update msg model = (model, Task.attempt FooLoaded (getItem "foo"))


I guess values received in ports come as subscriptions and from there go

into the reducer, but I imagine Tasks are more composable? Like JS Promises?

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