First of all I have to say I'm really glad we have this discussion. I know
it's sometimes frustrated to face different opinions but outcome is
definitely worth it. It looks like we're really not on same page and can
learn something from other here. Also it seems that groups are good place
to
I would like to help with this by contributing some version.
Anyway it's crucial to point out that this is really not easy thing to do.
I like idea with MusicBrainz db but that doesn't include changing data on
server. Also it's hard to demonstrate scaling without some noise (unrelated
business
>
> That appears to have much in common with our app. It seems useful to
> compare what people building SPAs are currently doing so here's a rough
> gist of the folder/file structure that we're using
> https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec. There's a
> few differences
>
> Marek,
>
> One difference might be that we don't deal with sign-in in SPA itself.
>> We're using Html.programWithFlags and passing user info to elm on
>> embedding.
>
>
> Good stuff. Less work when you don't have to worry about auth states.
>
it's helping us a lot. Anyway this
Richard,
What I'm saying is that *individual functions*, as opposed to *a group of
> functions and data structures* (model, view, update, msg, etc) is the
> right unit of composition.
I struggle to understand to see where is a difference. Html.program
constructor is record of functions as
I really feel you get the whole idea, brilliant!
I don't really know what I should add to that but at first - *Package was
taken down on my own request.* At this point I agree that term component
even though it might make sense from some point of view isn't really the
best choice. Also in
*reposting due to nonsense in code example - Can't write without Emacs,
sorry:(*
I really feel you get the whole idea, brilliant!
I don't really know what I should add to that but at first - *Package was
taken down on my own request.* At this point I agree that term component
even though it
Richard,
this is what you said about composing update functions:
> I'll reiterate that thinking about application organization as "composing
> TEA-shaped units" is neither officially recommended nor what Elm is
> designed for...
> > How do you propose to split the functionality one has
Erik,
Marek, about the tea-component package: If you're discouraged by the
> boilerplate for nested update and view functions, you can clean-up the
> boilerplate with a single function each... no need to create an entire
> abstraction package.
>
that sounds like what we do now. First of all
Sometimes you don't need subscriptions if you're in some state. For
instance, if you have game and subscription to say mouse position you can
subscribe to Mouse.position only when a user is in play state and avoid
subscription in game menu.
--
You received this message because you are
I agree with Alex in all his points - ports are a better way to achieve
this. Btw () (0-tuple) is unit type
(https://en.wikipedia.org/wiki/Unit_type). *I'm saying that only so there
is any additional value in my comment other than +1 for Alex*
--
You received this message because you are
>
> And, is it just me, or does anyone else think the "cascading" feature is
> just a fundamentally bad idea?
I rather don't say bad but it can definitely get our of hands pretty badly.
We're using external stylesheet (sass) but with strict guidelines. Instead
of generating styles directly
I haven't found interop or missing FFI to be as problematic as some others
it seems. First of all I don't think it makes much sense to embed Elm to JS
if you can't reasonably shape surrounding JS system and it's API to elm.
We're using svgs as well a lot for charting. Anyway since it's quite
Hi folks.
I really respect Duane's opinion and right to move on. Anyway since
recently I've participated in some kind of dissolving of this community...
*original thread:
https://groups.google.com/forum/#!topic/elm-dev/iqErmKHnLDY
I think having drop down component would be really valuable. Anyway I think
that implementing some reusable component what ever complicated it might be
is far from "scaling elm". Designing reusable parts of UI is not necessary
same thing scaling application code base.
--
You received this
Hello Ana!
Since no one have commented more on this thread for some time I'll add some
addition points to Peter's answer myself.
First of all I think that you might misunderstand what tail recursion is
but that's OK. I encourage you to look for some nice explanation on
internet. I saw many
Hi folks!
Ossi just announced open-sourcing of one of their (Futurice) projects on
twitter.
twit: https://twitter.com/ohanhi/status/859664021150158849
repository: https://github.com/Tradenomiliitto/tradenomiitti
these are statistics of that project (I'm using cloc)
github.com/AlDanial/cloc v
Interesting project!
We had this problem too but have decided we don't want to lock us to
webpack so much (even though we're currently using it). If you're
interested you can have a look at
http://package.elm-lang.org/packages/GlobalWebIndex/class-namespaces/latest.
Simply we're just
My thoughts:
- Most packages don't depend on `elm-lang/html`
- Most examples do depent on `elm-lang/html`
- It's good to enforce examples compatibility <-> library compatibility
in CI (compiling examples in some step)
Solution?
- have `elm-package.json` without `elm-lang/html`
It's clearly great contribution to educative materials around Elm. I've
seen your tweet before and was really pleased you've found time to build it
- give it your likes folks.
About web-pack - even though we're using it with elm in company project I
never used it for any of my hobby project
Folks. I feel this thread is maybe not the best place to discuss certain
details of topics that raised in discussion. I feel there are too much
topic being actively discuss right now and it starts to be pretty hard to
follow everything. I feel that understanding what others are talking about
Unit () and integer are different types, therefore, a function that takes
>*either
Int or Unit<* isn't compatible with elm type system (I think it's actually
a property of System F - https://en.wikipedia.org/wiki/System_F but don't
quote me on that).
However, you can construct either type like
Reading assignment one more time I think it's fair to add laziness to the
mix. This is lazy version https://ellie-app.com/g3Z6VS9YCa1/2 (can't test
it though as ellie is broken at the time of posting this)
--
You received this message because you are subscribed to the Google Groups "Elm
23 matches
Mail list logo
