Hey Rupert. I'm not comparing web components to ports. Of course ports are a standard, important part of elm. My comparison is to native elm, which is different. For example,
https://github.com/elm-lang/persistent-cache/tree/master/src/Native Ports can't break the debugger's guarantees because the debugger doesn't run port code during replays. On Friday, March 24, 2017 at 4:29:53 AM UTC-7, Rupert Smith wrote: > > On Wednesday, March 22, 2017 at 11:57:22 PM UTC, Maxwell Gurewitz wrote: >> >> Hi all. I'm creating this thread to discuss the relative merits of web >> components and native code. >> > > One of the merits is that you can avoid ports to some extent, because a > web component can be set up by passing it attributes or properties, and can > tell your Elm code about events through custom event handlers and using > Html.Events.on. > > Perhaps this is why you get the impression that web-components are favored > over ports? > > I think the custom event handler can be very useful and save on Elm coding > needed to set up a subscription. Of course, there is no need to use the web > components standard to do these things a minimal amount of javascript can > be used instead. > > I think you are somehow getting the wrong impression that web-components > are favored. They can be problematic as mentioned already - placing them > within the DOM that Elm controls can lead to them being re-rendered and > losing their internal state. There is an impedance mismatch between > web-components which are object oriented and encapsulate state and > functional Elm code that does not. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
