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
