Outstanding issues before 2.7.0 release

[bob2517]

This is a placeholder for my benefit as I test things before 2.7.0 release, for things that are not necessary quick fixes.

Just discovered that reactive array variables aren't working when the inner bracket content is a variable, so this needs fixing:

@for n from 0 to 3 {
    render-after-end: "<custom-square len=\"{{theLen[n]}}\" col=\"{{theCol[n]}}\"></custom-square>";
}

The fix for this is to resolve the inner brackets fully before the reactive reference is stored, rather than storing the inner bracket variable which I suspect is being done. The reactivity needs to happen on the exact variable that is rendered.

[bob2517]

The variable is being additionally substituted in with quotes, as well as an issue with the inner scope reference problem.

[bob2517]

Problem is prior to render being called - issue with prior escaping rather than the render flow itself.

[bob2517]

Escaping issue has been isolated and fixed - bit obvious in the end. I'd moved something to be more generic and forgotten to take care of something in the process. There's still an issue with resolving variables in this scenario though as the [n] is staying constant when reactive vars are updating. Should be an easier fix than the last one though - that took hours of track-down to ultimately do a 2 second fix.

[bob2517]

That looks like it's solved - minor fix and very isolated in scope. Will commit shortly once I've removed the gazillion console logs.

[bob2517]

Fix is now on branch, this use of reactivity works as expected now:

@for n from 0 to 3 {
    render-after-end: "<custom-square len=\"{{theLen[n]}}\" col=\"{{theCol[n]}}\"></custom-square>";
}

[bob2517]

More obscure bug. This isn't parsing correctly in the code editor on the standalone version of the docs:

set-attribute: notif "Stopped";

It's being placed into the iframe like:

set-attribute: notif "Stopped";

and so it isn't parsing correctly when the inline ACSS loads. It works fine on the regular offline and admin versions of the docs website. The bug is probably related to the recent 2.7.0 stuff. It can be repeated by refreshing the page and by clicking on reset in the code editor. Re-running gets it working. It's on the shadow DOM events example. It works fine on the component events example. It shouldn't be anything to do with shadow DOM rendering though, because it doesn't get that far - the error is in the inline ACSS which is placed in the iframe before the code is actually run for the example.

[bob2517]

It's most likely some inner quote escaping that is causing the problem. The variable content containing the style is probably incorrectly inside quotes, and it thinks that it needs escaping. Possibly a variable assignment thing. If so, the error might be the fact that the variable has unwanted quotes wrapping around the content. Regardless, the error is brought about through code in the code editor rather than the example itself, so that is the area to trace.

[bob2517]

A note on what makes the standalone version different to the other versions of the docs. All the examples are stored in templates and pulled up as needed for each page as it's an SPA in the most accurate sense of the word. So the error is going to be during the template rendering step.

[bob2517]

Yep - the escaping is fine in the example template itself so it isn't a server-side issue. The quote is converted after that.

[bob2517]

The error actually happens prior to the code editor - it's in the website config for the standalone docs and needs tracing from there - before the code editor even starts.

[bob2517]

There's an additional error - the rendering of the iframe on the standalone version is happening 4 times rather than just the once like the other websites, so there's an additional issue complicating things to do with conditional handling somewhere or another. And that's happening on all the code editor pages, not just this specific example. Could be a side-effect, but maybe not.

[bob2517]

Config is loading twice on the standalone site, hence the multiple renders. That explains a lot. If it's loading twice as inline, it is possibly hitting the page more than once, one way or another.

[bob2517]

This double config loading needs to be fixed before the other bit. During the fixing of this latest bug so far, I refactored the acss code editor to use @if statements just to see how it would cope and I fixed a couple of core things that came up to do with @if handlings to get it working generally. To attempt to fix this particular bug though, I undid the changes to the code editor so that I've got the old version (which should still work for backward compatibility). So not a complete waste of time today.

[bob2517]

Inline loading is not being triggered from node mutations, so it must be adding through the more optimized one-flow render process.

[bob2517]

Been busy this week and next 2 weeks due to a vacation and starting a new full-time job, hence a little bit slower than usual with the updates. But normal service shall be resumed. Apologies if anyone is waiting for something. Please let me know if this is a blow to the nuts, as I can prioritise things when I'm able to.

[bob2517]

The double config error on the standalone site is because it's also grabbing the second template stored for that site. Doh. Good news that the error isn't in the core though. Just need to do something about that second ID grab - probably just check for containment in a template. Would be nice to not have an option to not have template contents searchable by the DOM - it invalidates the point of having reuseable code as it's very easy to get duplicate IDs because of this. Back to this later after work.

[bob2517]

Double config error has been sorted - it was a compilation error on generating the standalone site. It wasn't a core error. Will go live when 2.7.0 gets released.

[bob2517]

Boom - code editor sorted out and upgraded to use the new 2.7.0 control flow, so it's easier to read and shorter in code. Will be back on this issue shortlyish.

[bob2517]

Back on this.

[bob2517]

I'm aiming for a release today - just wrapping up the docs. It's going to be in the next few days now anyway unless I find a show-stopper - very close now.

The docs site really needs a revamp - it's evolved into something larger than it needs to be now and is probably overly confusing. That will happen when the switch to Action CSS happens - I'll halve the docs size or something like that. Meanwhile the current format is ok while things are evolving as they are.

[bob2517]

Good progress on docs today - loads of new examples and an updated code editor and all seems fine, from what I've addressed at least. Just need the give the docs a final read to make sure I've not left anything in there that's silly. So I should be able to get a release out tomorrow evening. I start a new job tomorrow but I hope to have enough brainpower to do it by the end of the day.

[bob2517]

I think that's a wrap with the docs - I've reviewed them this evening and amended a few things, including fixing a late breaking error on the @for loop (which was just a typo thankfully). I'm a bit pushed for time now so will push a new release with accompanying code editor and standalone docs site live tomorrow evening.

[bob2517]

Closing, going live.