> > > - Isolate state. > - Pursue immutability and idempotency. > - Separate state changes from presentation changes. > - Don't be afraid of transforming state into the minimal > representation necessary for display. > > Just wanted to briefly chime in and mention a great architecture video from a previous WWDC:
*Advanced iOS Application Architecture and Patterns: https://developer.apple.com/videos/play/wwdc2014/229/ <https://developer.apple.com/videos/play/wwdc2014/229/>* It's kind of iOS specific but expands on a lot of the points Richard mentioned in his bullet point list as well as framing a lot of those objectives around 'sources of truth' in your application. On Tue, Apr 12, 2016 at 1:49 PM, Richard Newman <rnew...@mozilla.com> wrote: > Emily has recently been exploring state-driven frontend design on iOS for > her menu work; I'd like to see her chime in here with her experiences. > > My 2¢: > > >> I've noticed that these patterns are not something that we've been >> explicitly doing on this team but could potentially benefit from – does >> anyone have experience with them? It would be great to hear some of the >> trade-offs and I'd be curious to see which parts of the code could benefit >> from a more formalized architecture. Experience with these architectures on >> other platforms (e.g. MVC in web dev) would also be useful to hear! :) >> > > To raise the level of abstraction here for a moment: architectural changes > over time have been about recognizing incorrect couplings and resolving > them. > > For example, one of the shifts between old-school MVC and more modern > approaches like React/Redux and MVVM is the recognition that one Model > doesn't fit all. MVVM transforms a model into a view model; React chops an > app state into simpler component properties as it filters down the tree. > > We see/saw this incorrect coupling throughout our apps: the broken > Site/Table concept on iOS, for example. Anywhere you see lots of > optional/nullable fields and a symmetric API, you have a poorly fitted > model. (This is one of my criticisms of simple ORMs > <https://160.twinql.com/trivial-sql-orms-considered-harmful/>.) > > Eventually this shift leads to concepts like CQRS and event sourcing, > where we acknowledge that the actions your user takes, the persistent > storage, and the data your frontend needs are all quite different, and can > be related by a transform pipeline. > > Jeremy Miller noted re CQRS > <https://jeremydmiller.com/2014/10/22/building-an-eventstore-with-user-defined-projections-on-top-of-postgresql-and-node-js/> > : > > “In a way, CQRS just explicitly calls out a large part of software > development efforts that is often overlooked. If we simply accept the idea > that different consumers and producers of the persisted state in our system > naturally have different needs as far as how the same information is > written, structured, and consumed, CQRS isn’t really “crazy talk” or extra > work.” > > > Another example: iOS developers noticed that controllers — in part because > of the delegate/datasource pattern — end up huge > <https://twitter.com/Colin_Campbell/status/293167951132098560>. You have > a tiny model (an array of records), a generic table view, and a gigantic > controller that looks up records, issues new queries, builds cells, handles > clicks, shuttles things between threads, and so on. > > Massive view controllers (e.g., BrowserViewController on iOS, BrowserApp > or GeckoPreferences on Android) are hard to test and hard to understand, > and they often start to take on a hybrid role as a kind of persistent model > themselves, which makes things even worse. > > One of the central benefits of tools like Redux and approaches like MVVM > is the isolation of state and changes to it: eventually the concept of a > controller/presenter is whittled down, because actions are handled > externally (reduced into a new state), and components simply present > themselves based on each new state. You can test your actions and your > components separately! > > I would be hesitant to recommend trying to retrofit MVC/MVP (or even MVVP, > or…) into Fennec. Instead I'd suggest following the *principles* that > each of these architectural evolutions is inching towards: > > - Isolate state. > - Pursue immutability and idempotency. > - Separate state changes from presentation changes. > - Don't be afraid of transforming state into the minimal > representation necessary for display. > > The right architecture for the situation will drop out from the > application of the right principles. > > -R > > _______________________________________________ > mobile-firefox-dev mailing list > mobile-firefox-dev@mozilla.org > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
