Duane,
I'm curious what the roadblocks were in the 2 of 3 you didn't have success
with? This could definitely help others when making their decision. Also,
it may provide helpful feedback to more appropriately prioritize future elm
platform development.
Thanks!
On Monday, April 24, 2017 at
Elm maintainers: where would be the best place to document this use case?
I'd hate for this to be lost in a sea of threads.
On Tuesday, January 31, 2017 at 10:41:51 AM UTC-6, Joe Andaverde wrote:
>
> The DOM could still be invalidated and redrawn at any time by virtual-dom.
> I haven'
cation
> to not unload any elements connected via ports and simply to hide them
> instead? Would certainly prefer your lifecycle events idea but thinking
> about near-term workarounds..
>
> On Saturday, January 28, 2017 at 11:27:17 PM UTC-5, Joe Andaverde wrote:
>>
>
Statement: Elm is difficult to adopt for some groups because they require
UI controls that may be difficult or time-prohibitive to re-implement.
Current Approach: Use ports to initialize controls by passing the id of a
DOM element to use as the container.
Problem: Using ports to wire UI
With the simplification of Elm since 0.17 it seems like there are far less
intermediate+ possible talks. I imagine the best talks will be about
tooling and not so much about the using the language.
What are some topics worth speaking about that are "beyond the basics"?
--
You received this
The rewrite of virtual-dom in 0.17 does not provide any mechanism for
knowing when a dom element is created, re-rendered, or removed. Which would
be essential for initializing a third party control.
Even in the version used in 0.16 I'm not sure the entire life-cycle for a
dom node was
