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 do that.
I have quite some points to ongoing discussion but I really have no time to put them down now since I have to work on things with colleagues. Anyway since nobody reacted on @peter's comment and I feel it really needs to be addressed let me add my opinion just on that for now: How about the case where one has calls to a server involved? for example a > weather widget or some kind of "Quote of the day" widget, a stocks ticker, > etc. > How does one handles side-effects (http, random, time etc) with this > pattern? Creating "components" that do any kind of HTTP is probably way to hell. The only exception are really simple things like let's say jQuery plugins or anything which is really really really super isolated. Generally networking should be on real surface of whole system. There are many things that can go wrong. This is the ultimate side-effect since one system talking to another over "Maybe Connection" doesn't have any guarantees about what that other system does. And you have to assume the other system will fail in one way or another. Dealing with failure is difficult itself and is hard to do in isolation of system since it pretty often has some impact of other things. *Api is the only real "mutable object" you have in TEA* (and you can write it in Haskell and do not change anything about this fundamental truth)*.* Api is actually global (your domain) mutable (even hello word "pure" can return error 500) singleton. People with some Erlang experience know costs of fault tolerance. I remember in some Evan's comment in Elm's either stdlib or compiler there was some note about OTPish (Open Telecom Platform) message passing. Anyway even thought Actor model is really great interesting model for concurrency it's crucial to understand it leads to some inherited complexity. We surly don't want to implement actors in Elm. Rich Hickey (author of Clojure) would probably said something like "Adding networking stuff to component is completing concerns of how to work with A and how and where to get things A needs". Also getting data is usually not the only thing you need to think of. Say you have Blog with posts and you're building admin. There is list of posts on left and post detail on right. Now you want to add "delete" function to post list so you can click on "delete" button and delete post. The right way to do it is emit some action from UI on click (This is what Html.Events do for you) and handle it on some very top/surface level - usually update but in case of composed updates (like "tea-component") on* the very top one*. Why? Because in actions like this you need to really look at system as whole. What should happen when user is trying to delete post which is actually opened? How can I tell if it's open (probably from route) and so on. Only on most top level you can control whole system (even though you might use higher lever interfaces of self contain units that if you have them). Of course there are exception but I would rather avoid examples of "component that can do http" since this is really where people can hurt themselves. Actually this is precisely why "tea-component" was using that "Action Bubbling" and and sending messages to upper component. Component might knows how to propagate "delete" action but has no idea about how to proceed delete. That is really concern for system as a whole. This is sort of same as Html.Events just on higher level. Child just asks "Hey this just happened and you might be interested" and system as whole knows how, when or if at all to do with it. This is at least what I thing based on my experience. Hope it makes sense. On Wednesday, April 19, 2017 at 6:56:23 AM UTC+2, Peter Damoc wrote: > > On Wed, Apr 19, 2017 at 2:58 AM, Richard Feldman <richard....@gmail.com > <javascript:>> wrote: >> >> "Everything ought to have the same API" is a much harder claim to defend. >> It sounds wrong at face value, and I haven't seen any evidence (in this >> thread or elsewhere) to convince me that it's a wise goal to pursue. :) >> > > But isn't the entirety of the html package and actual example of an > unified API? > All the widgets there have the same API: widget : List (Attribute msg) -> > List (Html msg) -> Html msg > > > checkbox : (Bool -> msg) -> Bool -> Html msg > > > > How about the case where one has calls to a server involved? for example a > weather widget or some kind of "Quote of the day" widget, a stocks ticker, > etc. > How does one handles side-effects (http, random, time etc) with this > pattern? > > > > > > > -- > 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.
