Conversation
index.dd
Outdated
| // Picking the frontpage example after the page has loaded leads to reflows | ||
| // and rerendering. Hence, we pick the example as soon as possible | ||
| /** | ||
| Bootstrap a parent node containing a <pre> element into an editor instance. |
There was a problem hiding this comment.
What does "bootstrap" mean here?
index.dd
Outdated
| return btn; | ||
| } | ||
| // helper method to construct a textarea in vanilla JavaScript | ||
| function createTextArea(className, value, text) { |
There was a problem hiding this comment.
This helper function is used only once, inline?
index.dd
Outdated
| return el; | ||
| } | ||
| // helper method to construct an editor overlay in vanilla JavaScript | ||
| // typically overlays are output,args,stdin and the editor instance |
There was a problem hiding this comment.
What does "overlay" mean here?
index.dd
Outdated
| el.appendChild(inner); | ||
| return el; | ||
| } | ||
| // JavaScript filter for humans |
There was a problem hiding this comment.
Pretty sure this function is not used for filtering humans. :P
|
Good stuff. I hadn't thought of actually putting the code inline, but this approach does have merits. I forgot we're already loading all our JavaScript at the end of the HTML, so there will be no libraries to use at that point. I wonder though if it's possible to reduce code duplication (if there is any) and the number of things that are in index.dd, e.g. by putting the JavaScript in a separate file and including it as a DDoc macro (e.g. js/index-examples.js.ddoc). It's not immediately obvious from the code (and I haven't looked at it in depth) whether this is what it already does, but doing just the bare minimum to show the example would be the goal for the inline JavaScript code. Showing the buttons and getting syntax highlighting for the editor working can be a task for the rest of the JavaScript code that's set up. The inline code's goal is to just do the bare minimum for the layout (ideally even avoid a re-layout later) and hand things over to the main code once it's loaded. |
The first commit is a more or less literal translation of the code in
I thought about this as well, but I wasn't sure whether it's worth the extra step.
Yes, that was my goal.
You need the buttons - they will trigger a reflow as well ;-)
Yes it does exactly this - I basically moved the entire layout setup function inline. |
c78067a to
c966202
Compare
c966202 to
a89a91b
Compare
Done. I think this is styling should get us started:
Done. I also tried to clean the script a bit further. For example, only the |
|
Looks nice :) @andralex What do you think? |
Why? Just reserve space for them. I don't understand why the code needs to do anything beyond displaying one of the divs that are hidden by default. |
index.dd
Outdated
| D=<span class="d_inlinecode">$0</span> | ||
| EXAMPLE=$(TAG2 a, id="a$1-control" class="example-control", )$(TAG2 div, id="a$1" class="example-box", $(RUNNABLE_EXAMPLE $2)) | ||
| EXTRA_EXAMPLE=<div class="your-code-here-extra" style="display:none">$(RUNNABLE_EXAMPLE $0)</div> | ||
| EXTRA_EXAMPLE=<div class="your-code-here-extra" style="display:none"> |
There was a problem hiding this comment.
EXAMPLE_ROULETTE_ENTRY sounds better to me.
index-examples.js.ddoc
Outdated
| Be careful, Ddoc forbids certain patterns, e.g.: | ||
| - using < or > | ||
| - direct assignments (foo = bar) are interpreted as new Ddoc variables | ||
| ) |
There was a problem hiding this comment.
What prevents adding this as a plain js file under e.g. js/example_roulette.js? Can ddoc string-import-mixin other files?
Is loading an external file via <script src="${DLANG_SITE}/js/example_roulette.js" type="text/javascript"></script> not an option? Or alternatively, mix the js script in, after ddoc processing, as part of the build.
|
Overall I really like the improvements in this PR (as an end-user), especially the added |
|
Thanks for your pull request, @wilzbach! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. |
|
Sorry, for the close - wrong button :( |
a89a91b to
1c800be
Compare
I thought about this for a while and while this approach has the disadvantage of potentially being a bit slower, it allows to use a proper JavaScript file (syntax-highlighting) and avoids the constant fights against Ddoc when writing inline JS. The simulated page load waterfall for "Fast 3G" shows this nicely: Of course the simulation, isn't perfect, but it does show that a lot of other stuff needs to be download before the page can be initially drown. DOMContentLoaded (the blue line) is at 4.13s
This would add another step to the build process and currently @CyberShadow is opposed to this (see e.g. #1688 (comment)). |
Excellent idea! But let's do this in another PR. This one is already big enough. |
| el.appendChild(titleEl); | ||
| el.appendChild(document.createElement("br")); | ||
| var inner = document.createElement(type); | ||
| inner.className = className; |
There was a problem hiding this comment.
So, the returned element and the inner "type" element have same class. Is that on purpose and why?
There was a problem hiding this comment.
Yes, because I tried to make a 1:1 copy of the jQuery version, see e.g. https://github.com/dlang/dlang.org/blob/master/js/run.js#L138
stdin = '<div class="d_code_stdin"><span class="d_code_title">Standard input</span><br>'
+ '<textarea class="d_code_stdin">'+stdin+'</textarea></div>';Imho "translation" and refactoring shouldn't be mixed (even though the temptation is very strong).
|
OK, so, as I understand, this PR does three things right now:
IMO these should be separate PRs, or at least commits. Also I still have a strong suspicion that the second one could be much simpler as mentioned above. |
|
@wilzbach something in this PR somehow broke the layout, see: (That's with Chrome 58 on Windows 10.) Last time I tried the DAutoTest preview (I think it was yesterday) I didn't notice any layout problems. |
1c800be to
7c6ca2e
Compare
-> #1767
Hehe. I initially had separate commits, but then squashed because it easier due to the several steps (inline Ddoc -> Ddoc as separate file -> separate Js). I for now simply dropped the commit.
Yeah, I realized this myself. Already fixed. Sorry. |
| // step 2: select the first <pre> element (of the .runnable-example <div>) | ||
| var el = findFirst(rouletteChildNode.children, function(e) { return e.nodeName == "PRE";}); | ||
| // step 3: Construct runnable example layout within the <pre> element | ||
| buildRunnableExampleLayout(el); |
There was a problem hiding this comment.
Also I still have a strong suspicion that the second one could be much simpler as mentioned above.
Yes, these lines without buildRunnableExampleLayout would - in theory - be enough. However, it still "jumps" due to the buttons added and just
- adding the buttons isn't a good solution imho, because (1) it creates code entanglement (at another random, JS place the script needs to be aware of this) and (2) it creates code redundancy and makes it a lot harder if someone wants to change the overall layout
- adding sth.
el.style.marginBottom = "20px"is a similar hack (and still flashes/"jumps")
7c6ca2e to
f478127
Compare
|
Rebased. @CyberShadow let's come to a conclusion here: are you okay with this now or do you want me to come up with an ugly hack that "fakes" the bottoms with sth. like |
|
Less code is better. There is way too much code with a bus factor of 1 on dlang.org already. As far as I can see, index.dd just needs like 5 lines of JavaScript, at most. If you don't feel like doing that, I can put it on my list. |
Opened another PR with this approach As mentioned the redraw flashes are still partially visible ... |
|
Closing this with regrets as it wasn't trivial to refactor the jQuery code, but in the end the smaller diffs won. |







As discussed here, to avoid page reflows, we should pick an example ASAP and render its HTML.
Unfortunately this required quite a bit of work as the original code heavily used jQuery for which we don't want to wait until it's loaded. I am not really happy with it, but I guess that's the necessary evil if we want to avoid the ugly page redraws (and don't have a server to do the selection).
That was fairly trivial to add and requiring a title for an example and reduces the manual checking from @CyberShadow ;-)
The example selector still needs styling, hence I am marking this as "Needs work" for now.