-
Notifications
You must be signed in to change notification settings - Fork 15
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
File loading #17
base: master
Are you sure you want to change the base?
File loading #17
Conversation
I'll take a look at this tomorrow. If you have a chance, would you mind re-syncing with the latest from cdglabs:master and uploading a new PR that only includes the file loading changes? It's a bit hard to review this way, and I'm not quite sure what the history will look like if I merge it like this...but I'm not an expert on GitHub PRs. |
Yeah I expected that Github would show this PR without the first three commits after the first merge. Apparently it doesn't do that. It's why I didn't make a PR for the file saving yet either. |
…leLoading Merge older changes into fileLoading
Oh alright, I've merged cdglabs/master onto fileLoading, and github automatically edited this PR. |
@@ -0,0 +1,26 @@ | |||
function createFileLoader (moonchild, channel) { | |||
var fileLoader = Object.create(null); |
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 variable is unused.
// the server requires a different websocket constructor, and it talks to multiple clients instead of one. | ||
if (typeof config === "object") { | ||
this.websocket = new webSocket.Server({server: config}); | ||
this.type = "server"; |
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 would be tempted to pass the type in as an argument -- that way it's clear at the call sites what kind of channel you are instantiating. It's a little confusing that the type of channel is determined not by the value of any of the arguments, but by the type of the argument. I think passing in the type as a string would make it a bit less confusing.
Another approach would be to create a ClientChannel and a ServerChannel constructor, and export only those constructors -- they could call the Channel constructor with the appropriate args. I'm fine with whatever you prefer though.
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.
Yeah, I think the way it currently is feels a little awkward, I don't like different constructors, because It's supposed to be the same api on the server and on the client.
Maybe something like this?
// client
var channel = new Channel({
type: Channel.server,
httpServer: server
});
// client
var channel = new Channel({
type: Channel.client,
port: 8080
});
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 like it. I would just do { type: 'server', ... }
, but it's your call.
|
||
window.getParameterByName = getParameterByName; | ||
|
||
function formatString(string, arguments) { |
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 looks like this is no longer used.
This is looking good! I'm happy to merge it as soon as you fix up the lint errors. Sorry it took a lot of back and forth, but I think the code is looking really good now. |
Oh that's no problem, code ended up a lot better than my initial request, it's really easy to overlook tiny mistakes. |
Do you get notifications when I push to this branch? I've fixed the linter errors, had to add an exception for a warning in the uriParser regex, as well as add |
@@ -9,6 +9,7 @@ | |||
"console": true, | |||
"module": true, | |||
"require": true, | |||
"window": true |
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.
Note the comment above: it says that if additional globals are required, they should be added per-file -- see http://eslint.org/docs/user-guide/configuring.html#specifying-globals.
I don't seem to get notifications when you push to this branch. Apart from the comments I just left, one more thing: the new files you've added are not being checked by the linter. Can you edit the 'lint' script in package.json to make sure that they are getting checked? And also fix the errors. I also noticed that the code under |
Yeah I noticed it was only linting the lib directory. Do you prefer 2-space indentation in the whole project? It's not consistent throughout the files. I strongly prefer 4-space indentation, I think it's far more readable. |
Yes, I prefer 2-space indentation -- but third-party code should remain unchanged. Which files are not using 2-space indentation now? I took a quick look and it seems like almost everything is. |
Oh now that you say it, it's probably because of my personal preference to do 4-space indent that I thought it was inconsistent, nevermind that |
Are console statements fine? ESlint is complaining about them, they're used throughout the project however. Should I add a global exception, or a per-file exception? |
Yes, that's fine given the nature of the project. Might as well add a global exception. |
Alright, no more linter errors, removed the common folder, and parseUri is the unmodified version. I think that's it! |
It all looks good, but one more problem -- the tests are failing. I think the simplest way to fix it would just be to move the client Channel into the editor. Then we can think a bit more about what the architecture should be. Or we just get rid of that test for now. It's not extremely useful. |
I could also add a check for
edit: Oh nevermind, that doesn't work.. It complains about any reference to window at all. The problem is that the test environment is not a browser, I'm not sure what you want to do with this. |
It's a bit of a hack, but sure, something like that is fine for now. |
It doesn't work though, because I get a websocket error after fixing the error. So I'd have to come up with another "fix" for that also, and for anything else. The real problem here is that the test environment is not a browser. Either the tests need to test only things that aren't browser dependent, or the test environment should be replaced. And otherwise, there are temporary solutions like moving the script or removing the test, but that doesn't really solve the issue. |
Well, the test is not testing functionality that is browser dependent. I think the issue is that the architecture hasn't really been thought through yet. For now I think the best thing to do is to move the channel stuff out of moonchild.js and into editor.js -- that way we can land this PR without a whole lot more work. After that, we can think a bit more about what the division of responsibilities between the various modules should be, and address that separately. What do you think? |
Alright that seems fine. It's not like this pr should be concerned with tests or architecture, it's just for file loading. |
I can't use |
Ok nevermind all this, it requires an avalanche of small changes throughout the project. I think it's best if the test gets removed for now, then think about the architecture, and then think about tests again. |
This pull request should be merged after the "fixes" one.
In this pull request, I've added the ability to load files by passing a filename to the
node server.js filename.js
command. This textfile will then be read, and sent to all open editors, that's not intended behavior, but that's how it works right now.What I've done is, I've made a very light abstraction over websockets, to make it easy to work with. The server-side one is server/channel.js and the client-side one is lib/channel.js.
server/FileLoader.js does the actual work on the server side. Whenever a new websocket connection gets established between a Moonchild instance and the server, if the server received a file via the commandline, then it opens that file and sends a "fileLoad" event using the channel to all clients.
The client then handles this "fileLoad" event in editor/loadFile.js. On "fileLoad", it simply sets the editor content to the received content.