We're using Ports to bring the data from js into elm.
On Wednesday, March 29, 2017 at 9:01:45 PM UTC-7, Christian Charukiewicz
wrote:
>
> Can you elaborate on how you are getting the data from the backend into
> Elm values? Are you not using Elm decoders? We use snake_case for all of
> our
I haven't looked into decoders yet. I'll read up on it and give them ago to
see if there's a performance advantage to doing it on the Elm side vs the
js side.
On Wednesday, March 29, 2017 at 9:44:11 AM UTC-7, Kasey Speakman wrote:
>
> Short of language changes, you could:
>
> * Use the infamous
>
> We have found that this pattern is typically a good case for chaining a
> bunch of andThen statements with a withDefault statement at the end
> together. The one thing is you would have to be able to adjust your values
> to all be Maybes.
>
Yes Christian, I am wondering if people are
It's an option in the browser-based rich text editor that appears when
posting/replying. The button looks like curly braces "{}". Highlight the
code you have written and then press the button.
On Wednesday, March 29, 2017 at 11:12:31 PM UTC-5, Duane Johnson wrote:
>
> May I ask how you
We have found that this pattern is typically a good case for chaining a
bunch of andThen statements with a withDefault statement at the end
together. The one thing is you would have to be able to adjust your values
to all be Maybes.
For example, if you have the following:
case someMaybeVal
Can you elaborate on how you are getting the data from the backend into Elm
values? Are you not using Elm decoders? We use snake_case for all of our
database fields, and writing decoders that will receive the JSON and
produce Elm values is a step we have to take with all of our data before it
I'm not really sure what are you suggesting, Mark. Is it's all really about
that CSRF token, then OK, I could have hide it behind opaque type and
expose just the bare minimum, so noone could tinker with it's value. Or I
could turn the simple architecture into more complicated (extra mappings of
While it cuts down on the boilerplate, it seems like this creates a fair
amount of exposure for what might otherwise be internal structures. For
example, if the page update functions all get and produce full models, then
each of the modules implementing those update functions becomes a place
where
The best solution to deal with your problems is to use Swiss knife of
functional programming, i.e.* function composition*. You would be surprised
how about anything could be handled by this *simple* technique.
Few weeks ago there was a question asked on Reddit about nesting data in a
model. It
Thanks for the explanation.
I understand the choices made so far, but I still haven't been able to find
good solutions for some simple problems:
1. I don't want to have every single possible message handled in the same
place. It gets too big.
2. My global update function deals with everything
The config approach pops up various places — e.g., elm-sortable-table — but
isn't as well specified anywhere that I've seen because it doesn't have as
clear a pattern to specify.
Cmd.map (and Html,map) come out of what could be called Classic TEA. The
classic Elm architecture was built to allow
Where can I find more information about that Config approach? I'm not able
to find a way to organise multiple page applications that I like.
On Wed, Mar 29, 2017 at 6:24 AM, Peter Damoc wrote:
> If you have a series of pages that each has Cmds and you have these pages
>
Short of language changes, you could:
* Use the infamous encoders/decoders to emit/parse pascal case.
* Use a header on the HTTP request to instruct the server to assume camel
case for the request.
Without pre-existing clients, I have the server emit camelCase (a
serializer configuration
Multiple times in my projects, I happen to need nested pattern matching.
Below is a raw extract of code (in an update) showing this need.
Study.ScribblesMsg scribblesMsg ->
case model.study.status of
Study.Progressing steps ->
case Pivot.getC steps of
Would you consider adding an option for users to disable the camel-case
requirement for record properties in the compiler?
Our use case:
We have a large legacy system we'd like to bring Elm into that uses pascal
case throughout (all database fields and all places they're referenced in
the
+1 - thanks for this
On Wed, 29 Mar 2017 at 14:04 Felix Lamouroux wrote:
> Hi folks,
>
> I have updated the elm-i18n tool to automatically convert between elm
> source code and PO/CSV-files.
> https://github.com/iosphere/elm-i18n
>
>
> This is currently "only" a node CLI
Hi folks,
I have updated the elm-i18n tool to automatically convert between elm
source code and PO/CSV-files.
https://github.com/iosphere/elm-i18n
This is currently "only" a node CLI toolset, but it is already backed by
elm at its core. In the coming days I will improve the elm code base
If you want a SSCCE, here it is:
https://ellie-app.com/M5sydznVwXa1/0
This is what you might be doing (the equivalent, of course).
On Wed, Mar 29, 2017 at 9:32 AM, Mark Hamburg wrote:
> I've now seen something like this a few times. The last time I tried to
> build an
I've now seen something like this a few times. The last time I tried to
build an SSCCE, the bug went away when I looked more closely so I expect to
get nasty messages from the bug submission system if I try to report it as
is, but I figured I would see whether anyone else has seen anything like
19 matches
Mail list logo