Tabris.js router #34
Tabris.js router #34
Conversation
src/api/router/Route.ts
Outdated
|
|
||
| export abstract class Route { | ||
| page: RoutePage; | ||
| options: RouteOptions = { |
There was a problem hiding this comment.
do we need this nesting? Why not directly on Route?
src/api/router/Router.ts
Outdated
|
|
||
| private _navigationView: NavigationView; | ||
| private _routes: ListLike<RouterConfig>; | ||
|
|
src/api/router/RouterHistory.ts
Outdated
|
|
||
| export type HistoryItem = { route: string, payload?: any }; | ||
|
|
||
| export class RouterHistory<T extends HistoryItem = HistoryItem> extends ListLikeObvserver<T> { |
There was a problem hiding this comment.
An observer must never modify the obversvee. These methods should be router internals, or RouterHistory class it wraps, not extend the observer.
src/api/router/RouterHistory.ts
Outdated
| export class RouterHistory<T extends HistoryItem = HistoryItem> extends ListLikeObvserver<T> { | ||
|
|
||
| public push(item: T) { | ||
| const source = Array.from(this.source); |
There was a problem hiding this comment.
This would replace the source even if it's a list. I'd rather deal with this using instanceof
src/api/router/Router.ts
Outdated
| } | ||
|
|
||
| set history(value: ListLike<HistoryItem>) { | ||
| if (this._routerHistoryObserver.source === value) { |
src/api/router/Router.ts
Outdated
| return this._routerHistoryObserver.source; | ||
| } | ||
|
|
||
| set routes(value: ListLike<RouterConfig>) { |
There was a problem hiding this comment.
Routes should be resolved via DI on demand (when they are needed). No property.
@Injectable('myRoute')
class MyRoute extends Route {
There was a problem hiding this comment.
We COULD enable another way to give routes IN ADDITION, but I dont think we should allow removing/replacing routes after the router was created.
There was a problem hiding this comment.
Can we resolve/create the object via class name? I'm trying to find the alternative ways to use the DI.
| } | ||
|
|
||
| protected _handleHistoryChange = ({deleteCount, items}: Mutation<ItemType>) => { | ||
| if (deleteCount > items.length) { |
There was a problem hiding this comment.
But you don't know where in the history the items were deleted. This assumes it's at the end. It also doesn't handle replacement.
src/api/router/Router.ts
Outdated
| private _routerHistoryObserver: RouterHistory; | ||
| private _routerMatcher: RouterMatcher; | ||
|
|
||
| constructor({navigationView, routers, defaultRoute, history} : RouterProperties) { |
There was a problem hiding this comment.
hmmm.... do we need a default route? What's the use-case?
There was a problem hiding this comment.
I think it's useful to navigate to the initial route
src/api/router/Router.ts
Outdated
|
|
||
| private _appendRoute(route: Route, payload?: any) { | ||
| if (route.page.onPayload && typeof route.page.onPayload === 'function') { | ||
| route.page.onPayload(payload); |
There was a problem hiding this comment.
The "payload" should be given to the route, not the page. Also, the entire item should be given so the router knows which kind of payload to expect. Also, it should just be a property like "item" or "historyItem", not a method with a name that sounds like listener.
There was a problem hiding this comment.
I thought "payload" would be uninteresting to a route because, only the page reacts payload and will do UI changes.
There was a problem hiding this comment.
the current implementation works as follows:
- create all routes and pages (UI).
- each page does UI changes based on the payload (that's why I named 'onPayload'). Even, the same page can use different payloads.
I've implemented without much investigation, maybe there are more robust alternatives to achieve the same behaviour.
src/api/router/Router.ts
Outdated
| route.page.onPayload(payload); | ||
| } | ||
| this._navigationView.append(route.page); | ||
| this._navigationView.drawerActionVisible = route.options.enableDrawer; |
There was a problem hiding this comment.
I think these two featues are a bit advanced for the first commit.
tbuschto
force-pushed
the
master
branch
2 times, most recently
from
36f18dc to
e90fd70
Compare
ahmadov
force-pushed
the
tabris-router
branch
2 times, most recently
from
3e3ebfe to
3bd65a5
Compare
ahmadov
force-pushed
the
tabris-router
branch
2 times, most recently
from
44aac30 to
57e82ea
Compare
No description provided.