On Tue, Oct 25, 2016 at 2:06 AM, 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote:
> I think the model that has the lowest 'cognitive overload' for a beginner > is to simply work with the request/response model of HTTP, and to request > data when needed, and POST data when you want to update something. Its a > pretty obvious abstraction and fits nicely with Elms event handling. > You are right if by "beginner" you understand someone new to Elm. This might not be true for someone who is using Elm to start learning to program. > I would say that persistence is not really the concern of the UI. It is > nice to experiment with clever technologies that let the UI code build > whatever query it needs, or update whatever data it needs but you have to > remember that most of the time your UI is not runnning in a trusted > environment - in the case of Elm/javascript its running in someones > browsers. Therefore it is almost a necessity that you create an API and > think carefully about what data can be seen through it, and what data > updated by whom. That said, Overmind has provided some clear details of how > access rights to data are protected when using graphql. Not sure if > PostgREST provides any assistance with access rights? > Browsers can provide a trusted environment through the use of https. This is what Gmail and Facebook and all other webapps are doing. Also, you are right, persistence is not the concern of UI but Elm is not exclusively about the UI. What I dream to have available is more like full stack in the browser. Something more like what Abadi Kurniawaan demoed at elm-conf. This is doable with the current technologies and would be a killer feature if Elm could do it right. > Coming back to the 'cognitive overload'... I have found that simply > setting up and working with the HTTP requests in Elm is a lot of work - you > need encoders, decoders, functions to help build the requests, functions to > help decode the responses and deal with errors, msgs to pass to update > functions to update your model based on responses and so on. There is a lot > of boilerplate in simply working with an API, although this has nothing to > do with databases and persistence as such. > I have had a similar experience and this is what motivated this topic. It is not that I mind the boilerplate all that much, it's that *I lose cognitive resources by not having an official/semi-official way to do it*. I keep asking myself if I took the right approach when I should be focusing on implementing some other feature. Why not just freeze dry your entire application state to some key/value > store (on every update), then you have a simple way to rehydrate the whole > application after a period of inactivity? > This is not an option on large datasets. I gave the example with the Music database in an earlier message specifically to address this. Pagination is a very real concern that seldom appears in toy examples. -- 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.
