TOPBAR
Planning Center application Topbar
Status
This project is under rapid high-level development. The immediate goal is to land on a flexble, stable API for all apps to move forward with new search and notifications implementations.
Helpful review and feedback
API and implementation feedback is very helpful. Feel free to file an issue or hit me up on slack. If you have an opinion on implementation, now is the time to voice it.
Because this project touches all apps, there are many stakeholders. Implementation details consider past, present, and future interests and make trade-offs accordingly. Please don't be discouraged if your feedback is dismissed because of interest and critia that aren't generally known.
Please withhold byte-splitting and micro-optimization feedback until the API is stabalized.
v1 will marke the stability of the component API and be a good time to circle back on performance optimizations.
Design desicions
There is no Topbar
There is no single Topbar. Each app has it's own composition of Topbar components that create that apps topbar.
Each team owns their Topbar
The goal of the new topbar is to empower app teams to develop search and notifications. Topbar is opinionated only about the placement of those components, not implementation. This lends Topbar to have a mix of composeable and replaceable components.
Composeable and replaceable
Topbar is implemented in a "2 + 2" manner. It's a bunch of pieces that can be used or not as each app needs.
The two opinionated components are SmallTopbar and NotSmallTopbar.
These are where the bulk of the non-negotiable decisions lie—sacred cows, if you will.
Topbar and SmallTopbar can be implemented simply by supplying them with the right props.
AppsProvider, ConnectedPeopleProvider, DisplaySwitch and others can be reimplemented to fit app needs.
Trade-offs
No dynamicic application support
Apps are currently hard-coded with icons, badges, and lockups. This means that an App can't use Topbar before support is explicitely added. Given that the apps is currently a fixed list and that the icons, badges, and lockups require design, this was an acceptable trade-off.
No Drop-in ease
This Topbar is not a drop-in
Initial render
The previous Topbar was a Rails view. This one is not. It was decided early that Topbar should exist in one language and library to limit complexity and reduce platform interest. Consiquently, there might be some early "initial render" delays. We'll determine the best solution for that in app rollout.
Known Improvements
These known improvements are intentionally deferred for either speed or flexibility.
Global
- remove lint setup in favor of TypeScript rules
- specify and extract
anytypes - build icon arrays from SVG directory
- rework DisplaySwitch to contain width concern and MediaSwitch to invert controller to owner
- better solve for all my
.toLowerCases()
Local
- #refactor-all-icons-to-32px-base
- #improve-outline-a11y https://hackernoon.com/removing-that-ugly-focus-ring-and-keeping-it-too-6c8727fefcd2
- #add-accounts-support