I think this would be great to have and would be glad to contribute. Just to be clear, you are proposing we come up with one set of functionality, that then multiple people implement using different approaches? Like TodoMVC, but a larger example that also encompasses server communication and build management?
I think the scope has to be really narrow and well-defined, and the domain pretty familiar to people already, for this to work. I agree with Marek that it needs some aspect of updating remote data. Re. MusicBrainz idea, perhaps something like a bookmarking or "my favorites" feature. Also, to simplify, perhaps there should be a 'reference server app' so that people don't have to implement that as well as the client side. I don't think we should assume 'serverless', i.e. client app talks directly to the service. Personally, I would like to see an example based around a multi-user app -- i.e., where multiple users collaborate on editing the same entities (not necessarily in real time). For example, a UI that models a simple workflow like *Alice creates a document that Bob can edit and then that Carla either can approve or send back to Alice and Bob to make further edits.* Maybe some example can be built around MusicBrainz that involves collaboration so the domain is not quite so boring :) My point is, TodoMVC and many other such examples are apps where each users owns his or her own data and there is no collaboration, and a minimal state machine. The weakness of these examples is they are utterly unlike most business applications. That's also their strength -- they are relatively easy to implement and compare :) On Wednesday, April 19, 2017 at 11:21:04 AM UTC-4, Marek Fajkus wrote: > > I would like to help with this by contributing some version. > > Anyway it's crucial to point out that this is really not easy thing to do. > I like idea with MusicBrainz db but that doesn't include changing data on > server. Also it's hard to demonstrate scaling without some noise (unrelated > business logic) and the same time do not introduce over-engineering at the > process anyone can use against whole idea. At least for me it's hard to > imagine scope of this. I also believe this is the reason we there isn't > something like this yet. > > Honestly ultimate solution would be to start some actually useful OSS > project which and solve some real use case. By that I mean something > bigger. @Oliver mentioned he has Ember background. In ember there is > Discourse and Hospital Run for instance. > Anyway now I feel I'm asking for too much and have doubts I'll be able to > contribute for project like this... sadly... It is just idea that come to > my mind. > > On Wednesday, April 19, 2017 at 11:11:05 AM UTC+2, Peter Damoc wrote: >> >> Hello community, >> >> Scaling Elm apps seams to be a recurring topic. >> >> I was wondering if maybe we could negotiate a minimal set of >> functionality, something similar to ToDoMVC, that could be implemented >> using different approaches to explore what could be the best way to >> structure the code. >> >> What should this minimal example cover and what this minimal example >> should be (topic)? >> >> I'll start the list with some bits of functionality that I would like: >> >> - multiple pages with common structure (sidebar/navbar) >> - navigation without reloading the app (SPA routing without the hash) >> - authentication >> - complex widget reuse (a module/widget that generates side-effects; e.g. >> a weather widget, some stock ticker, an ad provided by a third party) >> - styling (CSS) >> >> I would also like the example to cover real world concerns of: >> - using a build manager to integrate with other technologies >> - development mode - deployment build >> - testing >> >> As for topic, I was thinking about an interface to the MusicBrainz >> Database (a simplified interface). >> >> What do you think? >> What bits of functionality would you like to see exemplified? >> Are you aware of any other project (in other languages) that exemplifies >> a minimal set of functionality and could be used as a template? >> >> >> -- >> 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.
