Forwarding on to the larger list ahead of todays meet about AppState
---------- Forwarded message ---------- From: Emily Toop <et...@mozilla.com> Date: 5 May 2016 at 13:55 Subject: Re: [ios] AppState, MenuConfiguration, and prefs To: James Hugman <jhug...@mozilla.com> Hey. I said I'd give you a link to the branch I made for an interim AppState solution and my ideas for what it should be eventually. The branch for the interim can be found at https://github.com/mozilla/firefox-ios/compare/fluffyemily/Bug-1264638-app-state-upgrade The interim stage is just to improve on the current enums, make them more generic (and so more easily extendible) and get us in a place where we can move to the final stage more easily. Plus it is to allow the menu to detach itself better from the actual app state implementation in its protocols. (There is also a bunch of stuff on that branch that probably no longer needs to be there, but this was built on top of a Menu that is now fairly out of date. I'd need to cherry pick some fixes over from one branch to another I think to actually get this to work). Here, I've created a protocol for a StateProvider. This defines a contract by which one components can provide a state to anything that requests it. It provides an instance of AppState, that itself inherits from a State object that is defined within the Menu (This bit is messy. Haven't resolved it yet). Each components that has a state, then implements a struct that inherits from AppState. Here we have TabState, HomePanelState and TabTrayState. Those structs then implement those properties that they need to define their state. It is then an instance of one of these structs that gets passed into Menu, which expects anything that implements State. Where the app state is going, to move everything to a more reduxy methodology is: We have one app state only. This will be the domain of the root Reducer. The root reducer is the root of a tree of reducers. Each components will have its own reducer. Each Reducer will have its own state that it knows how to deal with. This state is contained within the state it's parent reducer knows about. Each reducer will perform changes on its components, update it's bit of state to the new state and return it to its parent reducer In this way state gets partitioned off to the correct components and the new state gets filtered on up to the parent reducer, which is where anything that wants to know about the app state will find it. I am envisaging our reducer tree will look something like this: RootReducer | - TabReducer - HomePanelReducer - TabTrayReducer - AccountReducer - SettingsReducer | - GeneralSettingsReducer - PrivacySettingsReducer - SupportSettingsReducer Which pretty much describes how the app state will look, the root AppState will contain an instance of TabState, HomePanelState, TabTrayState, AccountState and SettingsState and SettingState will contain an instance of GeneralSettingState, PrivacySettingsState and SupportSettingsState. Therefore when you access the root app state it will contain all of those things. The menu will then be passed all of the states so that any decisions can be made about what to display. Does that make any sense to you? We should meet for a chat to discuss it further. On 3 May 2016 at 21:53, James Hugman <jhug...@mozilla.com> wrote: > Background: > > We are trying to maintain some separation between MenuView code and the > rest of the app, with the intention that a) this is good for the code b) > MenuView could end up being a good candidate to be an open-source > sub-project unrelated to the main app. > > MenuConfiguration and AppState control what gets displayed as in a given > menu. > > AppMenuConfiguration is how the menu and tool bar should be configured > based on an immutable AppState. > > At the moment, AppState is very browser specific and not easily cleavable > from the rest of the app. > > This email is about using the existing prefs in the browser to influence > AppMenuConfiguration. > > MenuConfiguration has two properties > > var menuItems: [MenuItem] { get } > var menuToolbarItems: [MenuToolbarItem]? { get } > > I'm wanting to display different menu items depending on the value of a > Pref. > > In the feature I'm working on at the moment, this is display something > different if a pref isn't set, AND display in a different place if a > different pref is set. (i.e. two different things, and I'm sure this won't > be the last feature to want to do this). > > We've hemmed and hawwed at the AppState, and eventually decided that we > probably shouldn't do anything too ambitious/complicated to start with, and > see how far we get before > > So do we need an immutable copy of prefs to stick on the appstate? > > I understand there is a flux-wards direction to our intended architecture, > but I'd like to discuss a) how soon, how far do we want to go, b) what we > want to compromise upon/what technical debt do we want to incur to ship > this feature. > > – James > > >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
