[elm-discuss] elm-seeds rocks!

[Lars Jacobsson]

This is not a question and I hope I this won't sound like spam. But I just 
want to give some praise to the fantastic Eric Person (is that his name??) 
and elm-seeds. https://elmseeds.thaterikperson.com/ 
44 episodes now posted at a regular interval - that's good stamina. Clear 
and to the point instructions, and great varied topics. I don't know the 
dude, but I know he is worth some public praise.

-- 
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: Html.Attributes.none

[Lars Jacobsson]

I'd back this too.

On Tuesday, January 24, 2017 at 11:21:31 PM UTC+1, Robert Lee wrote:
>
> Would anyone else find --Html.Attributes.none-- useful?
>
> none : Html.Attribute a
>
> Use cases look like the following. 
>
> 
>
> view: Model -> Html.Html Msg
>   let 
> onClickButton = 
>   case model.isClickedAlready of
> True -> 
>   Html.Events.onClick Submit
>
>  False ->  
>Html.Attributes.none
>   in 
> Div [onClickButton] 
>
> .
>

-- 
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: contentEditable and caret jumps

[Lars Jacobsson]

Yeah, the problem is that when we are talking about contentEditable divs and 
spans there is no "defaultValue" attribute!

-- 
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] contentEditable and caret jumps

[Lars Jacobsson]

I've got a problem. We need to use contentEditable elements and while 
editing them, the caret jumps to the beginning of the box everytime the 
model updates. This derives from the fact that the browser holds some state 
about the caret position outside the model (the horror), and we reset that 
brower caret state everytime we update.

There are ways to solve this by talking to js using textranges (eg. here 
), but I look at that as an implementational 
nightmare with possible performance implications and shaky browser support.

Since it is just a fact of life that the browser holds some state, I'd like 
to handle it by intentionally putting the Dom and the model temporarily out 
of sync. Meaning that when the model updates, virtual dom won't update the 
element we are currently editing.

However - and this is crucial - I still want to update the model onInput 
(practically meaning on every new character entered). I just don't want 
virutal dom to update the element then the new data hits the view.

Is there any way of telling Elm to not update an element (ie essentially do 
what shouldComponentUpdate does in React)?

-- 
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: Feldmans talk about impossible states

[Lars Jacobsson]

Yeah but that was kind of my point though. In an app where 'something' (using 
your example) is the main piece of data, say a list of todos, then I wouldn't 
want the whole slice thrown away on every update? Not too familiar with the Elm 
core so I dont know where to look!

-- 
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] Feldmans talk about impossible states

[Lars Jacobsson]

I'm sure many of you have sen Richard Feldmans amazing talk on impossible 
states from Elm conf. In there he uses a Union Type for working with his 
data
History = 
History =
{ current: Question
, others: List Question }

This essentially means every time we want to update something in the 
History, we'll have to use the "History" - constructor instead of the 
regular record update syntax ( { questions | ... } ). How does this impact 
performance? I've heard that regular record updates essentially reuses 
everything that hasn't been changed. But when we are using a constructor - 
do we get any reuse or are we creating a whole new questions object under 
the hood?

-- 
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: Naming functions

[Lars Jacobsson]

Ok Max, thanks I'll give it a go and see how it works out.

On Monday, October 24, 2016 at 4:13:33 PM UTC+2, Max Goldstein wrote:
>
> If you're going to refer to items by ID a lot, you should probably use a 
> dictionary keyed on ID. Assuming items is a record with an id field:
>
> { model |
> items = model.items |> Dict.insert updatedItem.id updatedItem }
>

-- 
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: Naming functions

[Lars Jacobsson]

| The names were inspired by Dict.insert and Dict.update, which were the 
closest to what I was looking for.

Yeah, I'm probably just too used to that dot notation.


I don't know why but
items.replaceItemById id item
looks better than
replaceItemById items id item
. Somehow it feels like a standalone function named "replaceItemById" won't 
give us a list in return. But taking your idea to heart this would then be 
something like itemsUpdateById

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

[Lars Jacobsson]

Hey you guys! I've started to build out my first real Elm app and I'm 
loving it. On my model there is a field called items

 Model
...
items : List Item
...

which is a list of the type Item. Coming from a rails mindset I created an 
"updateItemById" -function, which I use like this in my update
 case msg of
   ...
   OnSubmit updatedItem ->
   { model | items = updateItemById updatedItem }
but then it dawned on me that this does not read very well in this context. 
We'll be getting back a list of items, while "updateItem" implies that we 
are working with a single item. A CORRECT name for the function would be 
something like getNewItemsListWithReplacedItemById which works, but is not 
very elegant. Of course I could make it a little shorter, but you get the 
idea.

Any thinking going out there on around naming conventions OOP vs 
functional? I'd be grateful for any input on this matter of life or death!

-- 
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 name messages?

[Lars Jacobsson]

>
>
>
>
>- What is the system supposed to do: RegisterWithCredentials String 
>String
>- What happened in the system: ClickRegistrationSubmit String String / 
>TapRegistrationSubmit String String
>
>
> Let's have an argumented discussion around this :}
>

I think one of the main arguments for the *second* approach, is that you 
may want to reuse and action like "RegisterWithCredentials" in other 
messages. Hence it is better suited to be a regular function that can be 
reused. 

-- 
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] Post mortem for my first attempt at using Elm in a real app.

[Lars Jacobsson]

> If you implement the Router in Elm (the implementation starts with Elm), then 
> Pages are a reasonable abstraction. 

In this scenario - do you wire the state from each separate “page” up into the 
top level app.elm (or wherever the routing lives), or do you let each page 
manage it’s own state without any connection to the top level state? In other 
words: does your top level state look something like this:

{ activePage : String
, itemListPageState : List Item
, itemDetailPageState : Item }

or does the top level only hold its own state? Something like this:

{ activePage : String }

-- 
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: Post mortem for my first attempt at using Elm in a real app.

[Lars Jacobsson]

Thanks for a very informative answer! I think this is a very important part 
of making an elm application work when it grows. I'm pretty sure that we 
should be very careful before breaking stuff "prematurely". I started 
writing an app breaking it up like i used to break up my react/redux -apps, 
i.e something like app.elm -> itemlist.elm -> item.elm. It's a nightmare 
where you end up having to handle multiple levels of sub-messages and 
stuff. Breaking stuff up organically and trying to keep the types and 
update together as long as possible is the key and makes a BIG difference 
in how much fun the app is to maintain. I also believe we should not have 
multiple "pages" in the same elm app. If you have two "views" (like eg. 
"itemlist" and "itemdetail") - thats two separate elm apps!

On Tuesday, September 20, 2016 at 5:03:23 PM UTC+2, Peter Damoc wrote:
>
> On Tue, Sep 20, 2016 at 5:18 PM, Lars Jacobsson <lars.jac...@gmail.com 
> > wrote:
>
>> Peter - just out of curiosity: How did you split those 8000 LOC up? Did 
>> you go for a structured component/react type splitup, or did you split 
>> "organically" when the need occurred?
>>
>  
> It was more of an organic kind of split, mostly around functionality. 
>
> With the exception of some static pages that were handled directly by the 
> MainApp.elm, all the other pages had their own separate file. 
> Most of them were following TEA but some ended up not needing their own 
> model and update because they could delegate their actions to the top 
> level. 
> Functionality around routing was in its own file, same for the server 
> access API. 
> Business Objects Types were in their own file that was imported all over 
> the place 
> Serialization (encoders and decoders) was in its own file. 
> There was a Components.elm that was mainly various aggregates of elm-html 
> (simple functions). 
> There were also a few components (Dropbox, Carousel) that lived in their 
> own .elm files. 
> Some complex forms got also extracted at one point into their own files. 
> There were also some CSS only files. 
> One of them, SharedCSS.elm taught me a very important lesson:
> Don't put code that changes frequently in a file that is imported by a lot 
> of other files. 
> changes to this file led to the longest compilation times. :) 
>
>  
>
>
>
> -- 
> 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: Post mortem for my first attempt at using Elm in a real app.

[Lars Jacobsson]

Peter - just out of curiosity: How did you split those 8000 LOC up? Did you 
go for a structured component/react type splitup, or did you split 
"organically" when the need occurred?

>
>
> Another large amount of time was spent trying to integrate a carousel. I 
> ended up reimplementing a bare bone version in pure Elm. 
>
> By the end, the code grew to about 8000 LOC of 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: Post mortem for my first attempt at using Elm in a real app.

[Lars Jacobsson]

Peter - just out of curiosity: How did you split those 8000 LOC up? Did you 
go for a structured component/react type splitup, or did you split 
"organically" when the need occurred?


On Monday, September 19, 2016 at 3:08:43 PM UTC+2, Peter Damoc wrote:
>
> I keep postponing this for a few weeks but today my partner decided to 
> stop the collaboration and I'll take advantage of this moment to write this 
> post mortem. 
>
> *Context*
>
> I was approached by a friend few months ago about a B2B project that was 
> supposed to help small businesses issue beautiful invoices. It was suppose 
> to be a free product that would synergize with some other products that his 
> business was already delivering. I was supposed to implement it and he 
> would do all the marketing and promotion.
>
> Having total freedom, I decided to use Elm to implement the platform in 
> cooperation with another part-time programmer that would do a JSON backend 
> in PHP. 
>
> The product required that the interface would be modern, responsive, 
> dynamic and look great. 
>
> *Beginning Phase*
>
> The first phase of the development was dominated by personal attempts at 
> reimplementing reactive design elements such as drawers that show on big 
> screens and hide on small devices. After a few buggy attempts I ended up 
> trowing everything away and switching to elm-mdl. 
>
> A considerable amount of time was also invested at this point to set up 
> some kind of automatic build environment. I ended up with a solution based 
> on gulp. 
>
> *Middle Phase *
>
> Once the build environment was set up, things started to move a little 
> faster. I then ended up needing CSS and after playing a little bit with 
> elm-css and hitting several missing properties I decided to implement my 
> own library, taking inspiration from all 3 libraries that were dealing with 
> style (rtfeldman/elm-css, elm-style and massung/elm-css). In hindsight this 
> might have been a rather bad idea for productivity reasons but I have 
> learned a lot. 
>
> *Ending Phase *
>
> After I passed the 5000 LOC mark, things really started to crumble around 
> me. My mind could no longer deal with the complexity I have created. 
> Most of the brain cyles in this phase have been wasted trying to use the 
> little JS I know to try and somehow add to my Elm UI some widgets that I 
> needed. I have failed.
>
> I have spent an inordinate amount of time trying to add some Dropdowns to 
> some forms I had, ending up reimplementing part of them in Elm and using 
> some CSS form the Semantic UI project. 
>
> Another large amount of time was spent trying to integrate a carousel. I 
> ended up reimplementing a bare bone version in pure Elm. 
>
> By the end, the code grew to about 8000 LOC of Elm. 
>
> *Conclusions *
>
> - *Elm is an amazing language.* I've had countless moments of sheer 
> pleasure programing in Elm for this app. 
> - *Elm lacks the full story. *My main hope was that I could implement the 
> app even if I had very little CSS or JS knowledge. I could not do this. Elm 
> does not have yet something that would allow someone to stop touching CSS. 
> -* I would not recommend webdev beginners to take the approach I took.* 
> It is better for now to stay the tried and proven path and just use Elm to 
> implement smaller components in another web framework. 
> - *The tooling around producing a deliverable elm webapp are simply not 
> ready yet.* 
>
>
> Thank you for taking the time to read this. 
> If any of you has curiosities around this experience, feel free to ask me 
> anything. :) 
>
>
>
>
>
> -- 
> 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.