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
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
e 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
>
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
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
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
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
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
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
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 u
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
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
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
al 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
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
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', {
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
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
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
19 matches
Mail list logo
