-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Conversation
@@ -62,7 +62,7 @@ export default handleActions({ | |||
signerSuccessConfirmRequest (state, action) { | |||
const { id, txHash } = action.payload; | |||
const confirmed = Object.assign( | |||
state.pending.find(p => p.id === id), | |||
state.pending.find(p => p.id === id) || { id }, |
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.
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.
Might be. Just saw this issue once, so I guess it won't hurt to add this.
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.
Think it solves that issue. Still unsure exactly why it happens, it should have all the info. (Just a nightmare to replicate - I have tried.)
const BUILTIN_APPS_KEY = 'BUILTIN_APPS_KEY'; | ||
let dappsFetcherInstance = null; | ||
|
||
export default class DappsFetcher extends EventEmitter { |
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.
Not sure why this is not just a store that gets passed (or is a single instance). I prefer to stick to the same patterns for consistency instead of adding yet another way of doing things.
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.
So looking at where it was split from - rather use the store as a global instance (one existing), get it to update, share it as needed.
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.
The idea was more to have a store for data (that gets persisted throughout the session) and one for the UI, which is a MobX store with observers & all. The idea is that we might not want to preserve MobX stores throughout the app since they don't old any valuable data if the component is not mounted.
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.
In this case it is actually a "global" store - gets used in multiple places (should not have been re-instantiated) and the data is store anyway now.
Let's follow one pattern, not multiples.
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.
So where does this store should live ?
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.
For now, probably keep it in dapps (like the fetcher was), longer term we can probably s/redux/stores
and put it in there since it deals with all the global stores.
Changes Unknown when pulling 278fed9 on ng-better-loadings into ** on master**. |
@jacogr Ok so modified a bit how it works. Fetching dapps logic is now in |
Cool, will play. (As an aside, we definitely need a better place to put dapps.js/wallet.js/etc. - that folder is going to get out of control and it "feels" wrong just dumping all in there. No better ideas at this point and it is not a crisis, just something to keep in mind) |
Looks good, however just do the "Ethcore" -> "Parity Technologies" header updates. |
We shouldn't need to reload dapps on each visit to the dapps view/page
This PR adds a
dappsFetcher
that caches current dapps and their meta data.It listens to the dappReg events to update the image/meta-data if needed.
This prevents a high loading time on visiting the Dapps tab.