Persistence Manager #733
Persistence Manager #733
Conversation
|
|
||
| export const portfolioPanel = hoistCmp.factory({ | ||
| model: creates(PortfolioPanelModel), | ||
|
|
||
| render() { | ||
| return panel({ | ||
| tbar: tbar(), |
There was a problem hiding this comment.
Since the tbar component is so minimal and doesn't react to any state changes, I would just specify the tbar items inline (i.e. tbar: [persistenceManager()])
|
|
||
| export const portfolioPanel = hoistCmp.factory({ | ||
| model: creates(PortfolioPanelModel), | ||
|
|
||
| render() { | ||
| return panel({ | ||
| tbar: tbar(), | ||
| mask: 'onLoad', |
There was a problem hiding this comment.
Probably want to mask while the PersistenceManagerModel is loading views for the first time. Otherwise, this will render unmasked with whatever the default view is (in code) and then jump to the persisted view once it loads
|
|
||
| this.persistenceManagerModel = new PersistenceManagerModel({ | ||
| type: 'portfoioExample', | ||
| noun: 'portfoio', |
Added omitDefaultMenuComponent to config to enable omitting default menu component
| .linkTo(this.initTask); | ||
| } | ||
|
|
||
| private async _initAsync() { |
There was a problem hiding this comment.
I think our convention here would be to call this doInitAsync rather than the underscore (that tends to be used more for private properties than methods). But also curious why split this out at all. Seems like it could all just go in initAsync
| }); | ||
|
|
||
| await waitFor( |
There was a problem hiding this comment.
Couple thoughts --
lastLoadCompletedisobservable, so you can use mobxwaithere instead ofwaitFor. The difference is thatwaitForpolls on your specified interval, whereaswaitshould run as soon as the observable changes such that the condition in the callback is met.- Like we discussed
lastLoadCompletedruns whetherdoLoadAsyncresolves or rejects. This is a little risky, but our whole story around a failed load is at the moment... let's talk about this some more, or maybe just flag it as something we should revisit
There was a problem hiding this comment.
In general, this is an annoying amount of boilerplate you had to write! I wonder if there'd be a way to generalize this and build a higher order component / model to avoid some of this. Just brainstorming - what if the PersistenceManager component was a container that accepted a single child component that it would not render until it was done initializing. Big issue here is that ideally the child would create its model, so that it would not be constructed until the manager finished initializing. BUT we would need a reference to that model in order to wire it. Wonder if we could use modelRef to do that... but we wouldn't want whatever we do to be even more complicated / harder to reason about than what you have here...
Sorry for the flight of ideas - will think more on this, and maybe we can brainstorm together.
# Conflicts: # client-app/yarn.lock
Don't auto save when default view is selected
|
Picking this up with the latest WIP Hoist React APIs @ #737 |
No description provided.