[elm-discuss] Re: Post Examples of Painful Record Updates Here!

I have two real-world examples. Nothing is modified at all. 1. Update inner structure canvasPosition : Model -> Position canvasPosition model = let pos = model.mousePosition in { pos | y = pos.y - headerHeight } 2. Add field to make extended record (cannot use update

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

Here is a somewhat painful record update: setImage : String -> String -> Image -> Model -> Model setImage tool url image model = let mapping = case tool of "rectangle" -> .rectangle model.resourcesMapping "outline" ->

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

Hi Richard, this is not code that is in production yet and rather experimental, but I still think it might be worth sharing in the context of this thread since I had to write painful code to update nested records there (unfortunately, that code was never commited anywhere so I cannot share the

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

@art, I disagree about adding arbitrary expressions between { and |. You should use a let-binding for something like *Array.get (offset + i) arrayOfRecords |> Maybe.withDefault defaultRecord*. I know this is supposed to be pain points, not solutions, I'm going to try to coalesce some of the

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

It's not a huge deal but other strongly typed languages definitely allow arbitrary expressions in record update syntax. # type t = { a : int ; b : float } ;; type t = { a : int; b : float; } # let emptyT () = { a = 1 ; b = 3.0 } ;; val emptyT : unit -> t = # let x = { (emptyT ()) with a = 7

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

I have only recently begun immersing myself in Elm and have run into this quite early. Here's what I want to do and it seems very reasonable: type alias Model = { signup : Signup } type alias Signup = { email : { text : String, errors : String } , password : { text : String,

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

I just had a senior engineer on my team ask me whether it was really the case that putting a qualified name or a field access into the beginning of a record update would fail to compile. His examples were much like the other examples from this thread, but I'm noting this here to make clear that

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

Great post Mark - I've been working on a project lately and setters are fast becoming my #1 pain. I can relate to every one of those points you outlined, and you said it better than I could. On Thursday, March 9, 2017 at 11:09:22 PM UTC, Mark Hamburg wrote: > > I got asked for non

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

I got asked for non obfuscated/simplified examples, so let me run through some more realistic code. I would pull from our own codebase but we've often contorted ourselves away from these patterns because they are so ugly so I can't just grab existing code. Imagine having a style element that

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

I really want to just write something like: newmodel = { model | field.deeper.deeperer = "new value" } People have pointed me towards something Evan wrote about discouraging this, but I still don't understand why it would be a bad idea. It would reduce quite a bit of boilerplate. At the moment

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

Martin, Mark: do you have concrete examples of painful record updates? It sounds like with the thought you're putting into this, surely you're experiencing some significant pain. Examples, the more real the better, would be super! If you have suggestions, it would be more helpful to spin off a

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

Having built-in lenses would be great. I've been using evancz/focus for a while to allow the definition of generic form fields but it still required defining a Focus function for each record field. For example, boolField : Model -> Focus -> String -> Html Msg [ boolField model (record =>

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

I have an update function that has to call update functions for each registered page. The update function of the page itself only returns the page model and the command, whereas the main update returns it's own model (all pages) and a command. Here is the painful code: type alias Model = {

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

@Martin Bailey if I found myself with 50 messages in the model update I'd take as a sign that I need to abstract things more. Regarding the update of nested attributes, I agree that there is not a good way to do it, hence this thread. =) @Michael Jones Maybe something like this could work

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

Nothing special and I'm a beginner so I might be doing something stupid but I'm attempting to have some nested data in my model and this is the current state of one of my update functions which is fairly painful. update : Business.LocationList.Model.Msg -> Model -> ( Model, Cmd

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

Hi Francesco, thanks for sharing the example. I agree that's a good structure for different sections of an app. I oversimplified the first example to show the current necessity of updater functions. The more painful part is deeply nested records such as in my last Geocode example. I feel it

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

Hi Martin, I wonder if for your case a different way to organise your code would be viable: -- Family.elm updateFamily msg family = case msg of ChangeName newName -> ( { family | name = newName }, Cmd.none ) Save -> ( model, saveFamily family ) selectedView family = UI.form

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

Here are some real world examples of record updates that could be streamlined at the language level, including attempts to simplify UI code defining record updates. -- Update.elm update : Msg -> Model -> ( Model, Cmd Msg ) update msg model = case msg of Update updater ->

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

On Friday, March 3, 2017 at 1:12:39 AM UTC-5, Richard Feldman wrote: > > There have been various discussions of potential ways to improve Elm's > record update syntax. Evan commented that "(examples > design work) at this > point" - any potential designs for syntax improvements would need to be

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

What I find painful is when I need to check for cases inside cases in order to decide whether something should be set or should be kept. ( { model | mode = case model.mode of Drawing maybe -> case maybe of Just shape ->

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

On Friday, March 3, 2017 at 8:45:01 AM UTC-8, Mark Hamburg wrote: > > Our codebase suffers from this as well. > Mark, can you post some examples of painful code? As in, not just what you wanted to write but couldn't, but what you ended up writing that's still painful. Real code is much more

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

Here's an example of where record field pattern matching would make things more straight forward: case model.route of Routes.Entry { mode } -> if mode == Read then (hex "FF") else (hex "f6f6f6") _ -> (hex "f6f6f6") If we were able to

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

Our codebase suffers from this as well. And unlike what one of the follow ups noted, this isn't an issue of wanting to add fields. Rather, it's an issue of not being able to use an expression in the first part of the record update. In this case, one doesn't even need a general expression but

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

On Friday, March 3, 2017 at 12:15:59 PM UTC, Rupert Smith wrote: > > On Friday, March 3, 2017 at 6:16:15 AM UTC, Richard Feldman wrote: >> >> Re-posting the first example from Franscisco's thread >> : >> > > I think item 2 from

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

The Mantl UI combines several different kinds of data across a large platform-as-a-service-like system. At the top level, I'm handling messages for the model/view/update triples and handling routing. This may not be the *best *architecture, but it's what I came up with as a beginner and I

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

Noah posted an alternate syntax for JSON decoders that could make use of a better record update syntax. (post: https://medium.com/@eeue56/json-decoding-in-elm-is-still-difficult-cad2d1fb39ae#.ia6brcxw5) In short, he suggests decoupling the decoder order from the record order using the

Re: [elm-discuss] Re: Post Examples of Painful Record Updates Here!

Can we express these in terms of examples of real-world code that is currently painful? That's really the key here. :) On Fri, Mar 3, 2017, 4:18 AM 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > Another one I have run into, is when selecting just one field from a >

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

Another one I have run into, is when selecting just one field from a record, there is no syntax to further pattern match on it. Again, abusing the 'as' syntax in a quite different way to how it is currently used, something along these lines: func { field } = let SomeConstructor arg =

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

On Friday, March 3, 2017 at 6:16:15 AM UTC, Richard Feldman wrote: > > Re-posting the first example from Franscisco's thread > : > I think item 2 from Franscisco's thread is looking for an easy way to add and remove fields from a

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

Re-posting the first example from Franscisco's thread : There is a common pattern where a library (ex, elm-markdown) will provide a default config, to be extended by the user. Here the two ways to do this right now, one painfully