Re: [elm-discuss] Post mortem for my first attempt at using Elm in a real app.

[Peter Damoc]

Keeping in mind that this is a post mortem I could tell you what I did.

I had an activePage field that was used in the view to select whatever is
displayed.

I did not have an itemList state because all the information needed was
contained in a business object at the top level.

I did have state for the details page because that contained some of those
pesky small states needed for some UI that dealt with producing an artifact
from the details given.




On Thu, Sep 22, 2016 at 1:42 PM, Lars Jacobsson 
wrote:

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



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

[Peter Damoc]

On Mon, Sep 19, 2016 at 5:56 PM, Mark Hamburg  wrote:

> To Peter, then, goes the question: Which costs were just too much to bear?


Going to JS to do somethings is easy for non-ui needs.
One could use ports (or learn to use Native) and have some functionality
implemented using some other JS libraries.

The problem is when the JS stuff one needs is UI related like the JS
components that I needed.
The costs became too high when I tried to integrate widgets in Elm UI.
To be honest, I still don't know if this can be done in a reliable way.
Maybe it was just my lack of skill or maybe there should be a warning for
the people who what to start with Elm (as opposed to those who start in
something else and embed Elm)  to forget about all the JS driven components
when going for elm-html. :)
Also, I might add that not all JS widgets are created equal. Some get by
with just some class changes. These are very friendly to an Elm port.
>From my experience, porting the Dropdown from SemanticUI was doable,
porting JSSOR, not so much.





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

[Mark Hamburg]

On Sep 19, 2016, at 7:28 AM, Noah Hall  wrote:
> 
> I would agree though,
> that if you are intended to rely on the existing JS/CSS libraries out
> there, you are probably better off investing time in making Elm part
> of your site, not making Elm your whole site. You will spend too much
> time like this otherwise

Having spent plenty of times working with teams on mixed language/runtime apps 
over the last 13 years, I have had it hammered home for me that if you have to 
routinely jump back and forth across the fence and one-side of the fence is 
theoretically sufficient on its own, the insufficient side has to be incredibly 
compelling to make it worthwhile.

Applying this to Elm, the backdoor to JavaScript is vital to handle the cases 
that Elm does not handle, but every time one has to use that door, the value 
Elm needs to deliver in order to get one to come back goes up substantially.

Peter's case seems like it presents a useful opportunity to look at the balance 
of gains v costs. To Peter, then, goes the question: Which costs were just too 
much to bear?

Mark

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

[Noah Hall]

On Mon, Sep 19, 2016 at 3:08 PM, Peter Damoc  wrote:

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

elm-css is a complicated project. It's mostly complicated because of
_how big css is_. Reimplementing your own is not a reasonable idea for
getting things done :) A much better idea would've been to do one of:
1) fork, add the missing keywords, commit upstream
2) fork and add the missing keywords to your local copy
3) just use 
http://package.elm-lang.org/packages/rtfeldman/elm-css/5.0.0/Css#property
to achieve this without wasting any time messing around.

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

Elm hasn't considered this a goal since elm-html has existed. The
graphics library allowed you to forego CSS. Nobody uses the graphics
library in production (though many in academia (did)do, that's what I
did)

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

There isn't any reasoning here other than you tried to re-invent the
wheel a few too many times. I would also recommend to those trying to
solve a production problem to do the same ;). I would agree though,
that if you are intended to rely on the existing JS/CSS libraries out
there, you are probably better off investing time in making Elm part
of your site, not making Elm your whole site. You will spend too much
time like this otherwise

> - The tooling around producing a deliverable elm webapp are simply not ready
> yet.

You haven't provided an example of any tooling that "isn't ready yet".
You said you used gulp and there were no issues there. What were these
problems?

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