-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Conversation
@@ -1,6 +1,5 @@ | |||
.root { | |||
composes: border from "../../styles/colors.css"; | |||
overflow: hidden; |
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.
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"; |
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 can import multiple classes:
composes: border link from "../../styles/colors.css";
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. |
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 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? |
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.
No, we could pass just one option, no need for entire config 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. |
I repeated my experiment, see #86 (comment) |
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
I know. What I'm saying is that specific config option would need to be passed down all the way to
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. |
I’m fine with breaking change because we have one more coming — #134. |
@tizmagik fair enough. I'm ok with hidden by default. |
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. |
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. |
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. |
…howCode` from that `context.config`
Alright, I've implemented via The other two config-based properties ( I think this PR is ready to be merged now. |
constructor(props, context) { | ||
super(props, context); | ||
const { code } = props; | ||
const { config: { showCode } } = context; |
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.
const { showCode } = context.config
would be much more readable.
@tizmagik Could you please tweak that one line and I’ll merge the PR? |
@sapegin agreed and tweaked! :) |
Adds the ability to toggle the CodeMirror box:
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
After
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 totrue
so it's not a "breaking" change, or even add it as a config option. Let me know!