-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LocationHistory rework proposal #687
Conversation
Transition old -> new page (via go, next or back method): 1. call new.onbeforeload and wait for callback 2. replace old with new as the current page 3. call old.onafterunload
LGTM, but why do we need babel? |
@@ -0,0 +1,176 @@ | |||
/* eslint-env mocha */ |
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.
We should not need this because we are using standard.js?
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.
Yes. Mocha uses global functions, which cause standard.js to raise '{...}' is not defined
errors.
Actually, we don't. Thanks for pointing that out. Mocha threw errors on legit code and I thought it had some problems with ES6. However, as it turns out, adding |
Add --use_strict flag to Mocha instead of compiling with Babel
this looks very reasonable to me. thanks for adding tests for LocationHistory---they look thorough! webtorrent desktop hasn't had any tests so far. that was fine for prototyping. now that the app has good number of users (and features) i think it's worth the extra effort to make sure nothing breaks. two questions--not for this PR specifically but for WebTorrent Desktop in general
@feross thoughts? keeping the build simple is great. no babel ftw. |
'standard', | ||
'mocha', | ||
'babel-core', | ||
'babel-preset-es2015' |
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.
You forgot these 😉
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.
Oops! Thanks for that!
@@ -1,4 +1,4 @@ | |||
language: node_js | |||
node_js: | |||
- 'node' | |||
install: npm install standard | |||
install: npm install standard mocha |
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.
I don't prefer mocha
because it pollutes the global namespace.
@Goldob Great changes! This is good work. Thanks for doing this. I prefer @dcposch I don't think we should have any unit tests in WebTorrent Desktop. This app should be mostly glue code. That can be tested best with a few sanity-check integration tests. If there's a file that feels like it needs unit tests, then it should probably just be it's own npm package with it's own README, unit tests, etc. I'm going to pull out |
} | ||
} | ||
|
||
LocationHistory.prototype.hasBack = function () { | ||
return this._history.length > 1 | ||
return this._back.length |
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.
This should return a boolean, so this._history.length > 0
is better.
state.location.go({ | ||
url: 'home', | ||
onbeforeload: (cb) => { | ||
state.window.title = config.APP_WINDOW_TITLE |
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.
this is a good idea! there are actually more places where setTitle()
calls can be removed. i'll do that!
New PR here: #748 |
Relates with #653.
This is really just #656 after rebase. I decided to set up a new PR because Travis stopped responding to new commits and his output is crucial to illustrate the point (feel free to take a look at the unit tests).
With the proposed changes, a procedure for transitioning from
old
to newpage
will work as follows:new.onbeforeload
and wait for callback1new
as current pageold.onafterunload
21 This was not always the case in the old version
2 I decided it is more suitable than
onbeforeunload
, because when we clean view-related variables, we want to do it after we stop rendering the page (or we risk errors otherwise). Also, this eliminates redundant complexity from having twoonbefores
- e.g. what if one has completed successfully, but the other returned an error? Do we just quietly abort the page change? But then the view whose function worked properly doesn't even know it's not being (un)loaded anymore. Maybe we should call the opposing function to notify it? What if it returns an error? You get the point.