Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

Viewmodel phosphor widget implementation #4

Merged
merged 16 commits into from
Dec 1, 2015

Conversation

jasongrout
Copy link
Member

This implementation follows design discussions about designing the models.

@jasongrout jasongrout mentioned this pull request Nov 7, 2015
@jasongrout jasongrout changed the title Viewmodel phosphor widget implementation WIP Viewmodel phosphor widget implementation Nov 7, 2015
'use strict';

import {
ISignal, Signal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two leading spaces.

@jasongrout jasongrout force-pushed the viewmodel branch 2 times, most recently from e5fd283 to f7e15b5 Compare November 12, 2015 14:41
@jasongrout
Copy link
Member Author

@blink1073 - I cleaned up a lot and I think I fixed each one of your comments.

`
textModel.mimetype = 'text/x-python'
textModel.lineNumbers = true;
/* let inputVModel = new InputAreaViewModel();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

leftover?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep....more like, "preview of work to come..."

@blink1073
Copy link
Member

@jasongrout, are you ready to merge and iterate on this one too?

*/
constructor(model: ITextEditorViewModel) {
super();
this.addClass('CodeMirrorWidget');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be jp-CodeMirrorWidget.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't realize we had settled on a prefix. Sounds good.

@jasongrout
Copy link
Member Author

@blink1073 - sure we can merge and iterate from here.

this.addClass('InputAreaWidget');
this._model = model;
for (let key in InputAreaWidget.update) {
InputAreaWidget.update[key].call(this, model[key]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line is causing a build failure. It should be: InputAreaWidget.update[key].call(this, (model as any)[key]);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👎 on this flavor of dynamic dispatch. It's not type-safe and IMHO is harder to follow.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, this was one of the experiments, and I already decided to scrap it. I have some commits deleting it that I haven't pushed.

@jasongrout
Copy link
Member Author

ping @blink1073 - I switched back to using a switch statement

this._editor.on('change', (instance, change) => {
this._model.text = this._editor.getDoc().getValue();
});
model.stateChanged.connect(this._modelUpdate, this);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My convention for naming signal handlers is onThingSignalName, so for this case it would be _onModelStateChanged. Not saying you should follow this, just letting you know my convention. This let's me look at a method name and immediately make a good guess as to what it's connected to.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. Thanks.

@jasongrout
Copy link
Member Author

Thanks for the feedback.

/**
* Change handler for model updates.
*/
protected _onModelStateChanged(sender: ITextEditorViewModel, args: IChangedArgs<any>) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've been using a leading _ for private only.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thoughts?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to leading _ on private only.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Thanks.

@blink1073
Copy link
Member

Are we ready to merge this then?

@jasongrout
Copy link
Member Author

I rebased in order to remove the experimental js code, instead of moving it to a new directory. It's a lot cleaner that way, and the code is still in the history if we want to look at it.

@blink1073
Copy link
Member

LGTM, merge?

@jasongrout
Copy link
Member Author

I'm ready for it to merge.

We'll need to iterate on the tests.

@blink1073
Copy link
Member

Yep, iterating, thanks!

blink1073 added a commit that referenced this pull request Dec 1, 2015
WIP Viewmodel phosphor widget implementation
@blink1073 blink1073 merged commit f8960bc into jupyter:master Dec 1, 2015
@jasongrout jasongrout changed the title WIP Viewmodel phosphor widget implementation Viewmodel phosphor widget implementation Dec 1, 2015
@jasongrout
Copy link
Member Author

And now of course I see that I didn't update the readme nor did I delete the js tests...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants