-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Insert client implementation from within Dev Server API #1933
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
Conversation
We should add tests for clients before refactoring. If we don't, we don't know if it's really breaking changes. |
@hiroppy I know, I can write some tests. I just wanted to put the solution out for review and discussion, in case someone has a better idea of how to pass along the client implementation from the API to the client src. |
Is the only way of really testing the client to do |
lib/utils/getClientPath.js
Outdated
return require.resolve('./../clients/SockJSClient'); | ||
} | ||
|
||
module.exports = getClientPath; |
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.
It should be static method for SockJSClient, i.e.
BaseClient should have static getClientPath(options) { throw new Error('Need implementation'); }
and
SockJSClient should have static getClientPath(options) { return require.resolve('./../clients/SockJSClient'); }
For other clients too
const providePlugin = new webpack.ProvidePlugin({ | ||
__webpack_dev_server_client__: getClientPath(), | ||
}); | ||
providePlugin.apply(compiler); |
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.
As i said above SockJSClient.getClientPath(options)
if (handlers[msg.type]) { | ||
handlers[msg.type](msg.data); | ||
} | ||
}; | ||
}); |
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.
Will be great standardize client API, but we can do this in future not in this PR
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 you want to revert this and have the new client files, but not use them yet?
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.
Keep this as is in this PR, we discussion about this in future
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.
Some notes
Codecov Report
@@ Coverage Diff @@
## master #1933 +/- ##
==========================================
- Coverage 91.8% 91.45% -0.36%
==========================================
Files 23 25 +2
Lines 903 924 +21
Branches 283 283
==========================================
+ Hits 829 845 +16
- Misses 71 76 +5
Partials 3 3
Continue to review full report at Codecov.
|
Let's update snapshots (we will rewrite this tests in future) |
Update snapshots in this PR? |
Yes |
|
Looks good to me, but on the other hand, I am afraid of bugs by this change(of course in the future too). |
@hiroppy Agreed. Separate PR for new client tests? I will wait for addition of your jest jsdom tests and then work on adding more. |
@Loonride I think that it is good to separate PRs but at the next refactoring, I hope that a PR will have tests:) As a first step, I think that it is good to do a unit test. |
@hiroppy Do you mean I should do unit tests for the new components I've added (SockJSClient, etc.)? Because if you are doing tests for I'll also add more e2e tests in
Would you want such tests in |
if needed
I was going to mock this line(
I created a |
I am currently writing a complex e2e test, I will just put it in |
Yeah, that's fine 👍 |
And we should test using
We use babel, so it's ok. |
Can you rebase too? |
Something strange with CI, let's try to rebase as i said above |
When you say rebase does it matter if I do merge or rebase? Just curious. |
git rebase master |
Looks to fail to rebase.
First, you should run |
I think I mistakenly reset to |
Yes, you can open new PR if you don't know how fix this problem |
I think it is good now, just need to update |
Codecov Report
@@ Coverage Diff @@
## master #1933 +/- ##
==========================================
- Coverage 91.8% 91.77% -0.04%
==========================================
Files 23 25 +2
Lines 903 924 +21
Branches 283 283
==========================================
+ Hits 829 848 +19
- Misses 71 73 +2
Partials 3 3
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #1933 +/- ##
==========================================
- Coverage 92.42% 92.38% -0.05%
==========================================
Files 25 27 +2
Lines 964 985 +21
Branches 307 307
==========================================
+ Hits 891 910 +19
- Misses 70 72 +2
Partials 3 3
Continue to review full report at Codecov.
|
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.
LGTM
For Bugs and Features; did you add new tests?
Not yet, they will be necessary though
Motivation / Use-Case
The goal here is to make it possible for the Dev Server API to pass a local client implementation over to the client dynamically. From this, we can make the easy step of:
clientMode: 'path/to/client-implementation.js'
Breaking Changes
ProvidePlugin
does not cause problems for the compiler.Additional Info
__webpack_dev_server_client__
, not sure there is a better way though. Optimally, we could restrict this variable only to theclient
bundle that the Dev Server inserts.Edit:
class
on client side?