-
Notifications
You must be signed in to change notification settings - Fork 1.3k
For #5799: document architecture choices #5800
For #5799: document architecture choices #5800
Conversation
docs/architecture-overview.md
Outdated
- added complexity | ||
- distinction was removed | ||
- Rx | ||
- slowed startup |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Coroutines were actually worse until we implemented a fix in R8. Coroutines Dispatchers.Main blocked the main thread >200ms. Rx AndroidSchedulers.MainThread blocked the main thread 42ms on the same hardware. Coroutines are now faster because we strip out the wasted, blocking code using an early version of R8. Long story short, we were using both and had both blocking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good context, thank you
Isn't the |
For this doc I'm focused on describing what we have at present for new contributors, rather than suggesting any changes. That is definitely something you could bring up in future architecture work though! |
- Remove references to old architecture (Soon it will all have been replaced. No need for the additional cognitive load) - Add some subheadings - 'Simplified Example' seems like a good idea. Update the language to clarify that it will be done
Codecov Report
@@ Coverage Diff @@
## master #5800 +/- ##
===========================================
+ Coverage 14.3% 14.41% +0.1%
Complexity 324 324
===========================================
Files 259 256 -3
Lines 10700 10522 -178
Branches 1560 1532 -28
===========================================
- Hits 1531 1517 -14
+ Misses 9044 8879 -165
- Partials 125 126 +1
Continue to review full report at Codecov.
|
c9b7fed
to
12cd76a
Compare
12cd76a
to
b307fab
Compare
14818a8
to
b29e4aa
Compare
docs/architecture-overview.md
Outdated
- see `differences from previous architecture` for more in depth description of changes made to reduce complexity | ||
|
||
|
||
## Architecture Overview |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE TO REVIEWERS: the formatted version of this may be easier to review
EDIT: forgot I renamed that file. Link fixed
@@ -0,0 +1,159 @@ | |||
## Architecture Overview |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE TO REVIEWERS: the formatted version of this may be easier to review
EDIT: forgot I renamed that file. Link fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work @baron-severin! I've added a few comments but this is already super comprehensive.
Is pushed to: [Store](#store) | ||
|
||
#### Description | ||
Simple data object that carries information about a [State](#state) change to a [Store](#store). An Action describes _something that happened_, and carries any data relevant to that change. For example, `AccountSettingsFragmentAction.SyncFailed(val time: Long)`, which describes a sync that failed at a specific time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting we're not super consistent with Action naming. They can be reactive, describing something that has happened or active, describing something that should happen e.g. UpdateQuery
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think this is a symptom of some blending of responsibilities between Controllers and Reducers. When the Controller handles the logic, the Action winds up essentially being a setter.
a23bb86
to
939603d
Compare
939603d
to
25c668e
Compare
|
||
See [mozilla.components.lib.state.Action](https://github.com/mozilla-mobile/android-components/blob/master/components/lib/state/src/main/java/mozilla/components/lib/state/Action.kt) | ||
|
||
Created by: [Controller](#controller) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to list every possible thing that can create these? There are cases where Actions are created outside of the controller
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oof, I didn't realize. I know they used to be created in Interactors, but my understanding was that we were moving away from that and towards Controllers. Where else are they created?
EDIT: better question, is it fine that they are sent from a variety of places, or do we want them to only be sent by Controllers in the future? I don't have the context to answer this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome! I'm going to land this, do you want to update this wiki page with a reference to this? https://github.com/mozilla-mobile/fenix/wiki/Architecture-Decisions
Pull Request checklist
Documentation changes only
Documentation changes only
Documentation changes only
Documentation changes only
After merge
To download an APK when reviewing a PR: