Thanks for the extended feedback :)
I will be back here once I have something big enough!
Regards,
Witold Szczerba
On Wed, Nov 16, 2016 at 10:13 AM, Wouter In t Velt wrote:
> Op dinsdag 15 november 2016 23:03:31 UTC+1 schreef Witold Szczerba:
>>
>> Thank you, Wouter
Thank you, Wouter for explanation. I was reading the documentation, but the
chapter covers just the reusable views. View functions seems fine, using
modules one can create, group, nest, etc.
I am wondering how making everything "flat" scales in a long term. Having
everything in just 4 files
Op maandag 14 november 2016 02:24:16 UTC+1 schreef Witold Szczerba:
>
> Can you provide some real-life example of "moving away from components"?
> That could be helpful…
>
Sure. My background is in React, where everything there is components too.
No examples of my own to share just yet. My app
Hi Wouter,
you said:
> My own productivity in Elm has improved enormously since moving to flat
instead of nested, and moving away from components.
I am trying to get my head around Elm for some time, did not have an
opportunity to test drive it until recently. It's still extremely small
Definitely recommend simplifying it yep. :-)
Ports, in my opinion, should only ever go in one, fully-functional module
(I have it in a `Ports.elm` in my projects) that all things should share
through it. The global top-level update call should feel free to delegate
messages around.
On
Thanks OverminDL1 and Wouter In t Velt, I will try to explain how I have
come to this issue.
Originally, I have designed a web page (the "part") that was loading a
collection of images to display them.
So the flow was:
- init the elm page with a list of images urls
- [port] send the urls to JS
In your design, the port has a 1-to-1 connection to the Part.
The port does not communicate for which Part the incoming message is
intended, because it "expects" that their is only 1 Part.
Your batch function in the subscriptions in the Group.elm passes on the
port message on to all your Parts.
That is expected. Generally you'd have a uniquely named port per module
unless they really do all need to get the message. It might be better if
you describe what you are trying to accomplish instead of how to accomplish
it? :-)
On Tuesday, November 8, 2016 at 10:19:37 AM UTC-7, Matthieu