2016-12-20 Meeting notes
Date
Dec 20, 2016
Meeting Link
https://www.uberconference.com/villagereach-isg
Optional dial in:
Dial in: 213-493-0531
PIN: 74762
Attendees
@Josh Zamor (Deactivated)
@Elias Muluneh
@Pengfei Cui (Deactivated)
@Paweł Gesek
@Sebastian Brudziński
@Nikodem Graczewski (Unlicensed)
@Nick Reid (Deactivated)
@Brandon Bowersox-Johnson
@Ben Leibert
Goals
Discuss UI Extensiblity
Discussion items
Time | Item | Who | Notes |
|---|---|---|---|
5m | Start | Josh |
|
| UI Extensibility | @Nick Reid (Deactivated) | Part 2 on UI extensiblity |
Notes
Nick lead us through:
Multiple Suppliers - UI Extension Points
On adding a New Screen
This is easy and it's done.
Powered by UI-Router and NavigationService (Ref UI components). The UI-Router is an external project and our navigation service queries that to determine what to show in the nav bar.
Question: does this fork the reference UI
Answer: no, it’s dockerized and the new screen writer would have their screen in a git repo….
Question: is right’s (RBAC) covered?
Answer: yes, in the stateProvider there is a property, think it’s called accessRoles, that allows the UI-Router to understand the roles/rights needed to show the page.
On replacing a screen
this is hard and not done
there are two options being evaluated, a build process option (that overwrites the content of existing page at build time), and a UI-router option (which does so at run-time in the browser).
… this one is still a work in progress and atm there’s no questions/opinions on it.
On adding to an existing screen
this appears to be the hardest option and so it'd make sense to really consider the ROI of making a screen extensible ahead of time. There were multiple experiences added by participants that doing this sort of thing may never be worth it as it's difficult to go far enough.
Wrapping up
there is a question still: how to make it clear to an implementer what's supported in UI extensibility when looking at existing screens. i.e. for some screens it'd potentially be as much work if not more to make them extensible as it might be for an implementation to "override" it. The committee is going to have to make a decision on extensible screens v. overwriting in the next meeting.
Nick will have a part 3 to dive into this using some specific needs in the supplying partner scenario. The committee is going to have to weigh in on this decision:
how far does UI modularity / reusability go - adding new screens → replacing → extending
how will the project communicate, clearly and concisely, what the UI expectation and process is.
We will shift the meeting off a week. i.e. Jan 10th