Skip to content
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

Add code toggleability #150

Merged
merged 10 commits into from
Jun 13, 2016
Merged

Add code toggleability #150

merged 10 commits into from
Jun 13, 2016

Conversation

tizmagik
Copy link
Collaborator

@tizmagik tizmagik commented Jun 6, 2016

Adds the ability to toggle the CodeMirror box:

image

image

This may help address #86 but I'm actually not sure of the performance gains because I do not have a large testcase like the one in that issue. Below is the timeline for the basic example in the repo. You can see that rendering has improved and I imagine on a larger example case it could make a dramatic benefit. Either way, you can see that the 'Scripting' time is the big time suck, but that's a whole different story for another PR.

Before
image

After
image

I've also just done a very simple if (showCode) { ... } check, so not sure if there's an even more effective way to gain a performance boost by doing it another way or not, but at least it's a start.

It defaults to showCode: false in this branch, but I can have it default to true so it's not a "breaking" change, or even add it as a config option. Let me know!

@@ -1,6 +1,5 @@
.root {
composes: border from "../../styles/colors.css";
overflow: hidden;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Wasn't completely sure why this was here to begin with. I needed to remove it so that the show/hide code tab would look visually outside of the Preview box.

.codeToggle {
composes: font from "../../styles/common.css";
composes: border from "../../styles/colors.css";
composes: link from "../../styles/colors.css";
Copy link
Member

Choose a reason for hiding this comment

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

You can import multiple classes:

composes: border link from "../../styles/colors.css";

@sapegin
Copy link
Member

sapegin commented Jun 7, 2016

Cooool, thanks!

I think the default value should be an option but I’m not sure what value it should have. I’d make a breaking change if it really improves performance.

/cc @mik01aj @MoOx

@mik01aj
Copy link
Collaborator

mik01aj commented Jun 7, 2016

Looking at the graphs you sent, I don't notice any performance boost. :(

To me it looks like something is wrong, either with my analysis in #86 or with this PR. @tizmagik could you drill down to see what's the performance hotspot in your case? (I mean "after")

And from UX perspective: I would totally remove the "hide code" button if code is shown by default.

@tizmagik
Copy link
Collaborator Author

tizmagik commented Jun 7, 2016

I would say we should hide by default. It makes for a much cleaner presentation. I can add it as a config option to show/hide by default (although that would unfortunately mean we'd have to pass down the config all the way to Playground.js). If the config is set to show code by default then I can remove the "hide code" button, if you feel strongly, although it may be a bit confusing to lose that ability.

As for performance, again this PR isn't so much to address performance as it is to clean up the presentation slightly. I would also suggest we consider taking this a step further and include the PropTypes as part of the code to be collapsed, but I would leave that for another PR.

As for performance hotspot, in the basic example, the performance hotspot is definitely the Scripting rather than the Rendering. Although Render was improved by ~28% -- I just don't know what that would mean with a larger component base. Would anyone with a large component base be able to check out my branch and try it out?

@mik01aj
Copy link
Collaborator

mik01aj commented Jun 8, 2016

I would say we should hide by default. It makes for a much cleaner presentation.

Agree, but can we consider this a minor change? If not, the default has to stay as it is and we can change it in the next major version. I'm not sure if this kind of change is minor or major.

that would unfortunately mean we'd have to pass down the config all the way to `Playground.js``

No, we could pass just one option, no need for entire config here.

Render was improved by ~28%

Well, yes, but render is just 3% of total time, so this is not significant. I'll reproduce my measurement from #86, maybe something has changed in the meanwhile.

@mik01aj
Copy link
Collaborator

mik01aj commented Jun 8, 2016

I repeated my experiment, see #86 (comment)

@tizmagik
Copy link
Collaborator Author

tizmagik commented Jun 8, 2016

Agree, but can we consider this a minor change? If not, the default has to stay as it is and we can change it in the next major version. I'm not sure if this kind of change is minor or major.

I think it's fair to call this a minor change, as it doesn't remove any real functionality or change behavior adversely. It's simply a UI update really. But if you still feel uncomfortable about it, we can have the config change default to showCode = true, but I don't think that's ideal. For now, I'm going to default to hidden unless you guys feel strongly otherwise.

No, we could pass just one option, no need for entire config here.

I know. What I'm saying is that specific config option would need to be passed down all the way to Playground which I believe is 3 or 4 levels deep from where config is available. I'll see if I can figure out a clean way to do it, maybe context would be useful here.

Well, yes, but render is just 3% of total time, so this is not significant. I'll reproduce my measurement from #86, maybe something has changed in the meanwhile.

Yes, but I imagine for a large number of components the render performance gain would be commensurate. As for your run in #86 it does look like something has changed. I believe it may have been the performance improvements made in React 15.

@sapegin
Copy link
Member

sapegin commented Jun 9, 2016

I’m fine with breaking change because we have one more coming — #134.

@mik01aj
Copy link
Collaborator

mik01aj commented Jun 9, 2016

@tizmagik fair enough. I'm ok with hidden by default.

@tizmagik
Copy link
Collaborator Author

tizmagik commented Jun 9, 2016

Would you guys be okay with implementing this via context types? I just don't like how many layers I needed to manually pass this config setting down, and I think in general it might clean things up to have config available via context for whatever components need it now and in the future.

@sapegin
Copy link
Member

sapegin commented Jun 9, 2016

I like the idea of passing config via context. But I think renderer components should still receive everything via props to make replacing these components easier.

@tizmagik
Copy link
Collaborator Author

tizmagik commented Jun 9, 2016

But I think renderer components should still receive everything via props to make replacing these components easier.

That is a very good point. I'll see if adding config to context and then pulling in the specific values needed at the renderer component level is much cleaner or not.

@tizmagik
Copy link
Collaborator Author

tizmagik commented Jun 10, 2016

Alright, I've implemented via context. Good thing that I did, because actually I discovered a few places where I forgot to pass it around. Now via context its much clearer where that config setting is actually used and how it's made available.

The other two config-based properties (title and highlightTheme) are still being passed around manually, but I can refactor those to grab from context in a future PR.

I think this PR is ready to be merged now.

constructor(props, context) {
super(props, context);
const { code } = props;
const { config: { showCode } } = context;
Copy link
Member

Choose a reason for hiding this comment

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

const { showCode } = context.config would be much more readable.

@sapegin
Copy link
Member

sapegin commented Jun 13, 2016

@tizmagik Could you please tweak that one line and I’ll merge the PR?

@tizmagik
Copy link
Collaborator Author

@sapegin agreed and tweaked! :)

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

Successfully merging this pull request may close these issues.

None yet

3 participants