Closed bob2517 closed 3 years ago
Inline Active CSS has been upgraded on the 2.4.0 branch to work in SPA conditions dynamically. This was the first necessary step to make this issue easier to implement.
I've started this. It's going to be a stand-alone Active CSS component and shadow DOM based. In theory the code will be able to be copied by others. It'll probably call up ACSS, HTML and CSS files for each example via ajax from the docs server and it will have its own stylesheet. Details will be passed into the component via attributes. We'll see how it goes! It'll be a good way to demonstrate how to use components and should bring up anything that needs to be in the core that isn't currently and show up any bugs that are left. It's not going to have any persistence - I don't particularly want to get into having to use sessions, cookies or internal storage for this - it's just going to be a place to edit examples and try things out, and each example will have its own editor.
This is functional now as a code editor. I had to do a bunch of upgrades to the core to get everything to work as expected, but it's now fully functional and quick. Just need to sort out the peripheral functionality and the styling. I might put in a button to turn auto-re-rendering on/off. It doesn't auto-re-render at the moment, and I can see why people like it if you've got 3 boxes to edit. I don't do a lot of stuff on codepen - no need to use it at work or doing core work.
It'll need a reset button too. Gonna add that now.
It needs a core location attribute on the main tag too, so it knows where to get the core from in the result iframe. And an optional CSS stylesheet location for the inner iframe, and also another for the main CSS so people can change that if they want.
I was wondering how to assign a variable but only if it wasn't empty, and then I remembered that the var command evaluates a regular JavaScript expression, so I could do this below which is quite cool.
A check is needed to see if there is a base CSS stylesheet to add to the result iframe for basic styling under the docs website example output, but it's optional so I needed a condition. The $ makes the variable allow raw HTML, and the variable value is passed into the editor component via the attribute "base-result-css" on the \
var: $baseResultCSS ('{@host:base-result-css' != '') ? '<link rel="stylesheet" href="{@host:base-result-css}">' : '';
So the main editor CSS stylesheet and the result CSS stylesheet can now be set and passed in as attributes into the component, as well as the location of the core to use. So that's all the file locations and styles abstracted out.
Next is to get it looking a bit nicer. It looks like a knocked off codepen without resizable panels at the moment.
Reset button now works based on storing original ajax values of file contents. Had to do literally about at least 5 billion core fixes to get it to work in the area of scoped sub-components and variable handling, so that was worth doing. Looking good anyway. Everything else on the docs site still works, which is nice.
Going through the examples seeing that they all work in iframes that are hosting Active CSS. Finding and fixing a few things...
Note to self for a bit later: Build in a syntax highlighter as black text on a white background looks a bit crap. Just do the same regexes done in PHP on the server and translate into JS, working on the last word typed on a special character keyup. What could possibly be complicated about it? Famous last words.
Auto-refreshing results after a second of not typing is in place. Found a bug with the after event being used with a label which I've fixed offline.
All the examples on the docs website are working in the code editor now apart from the video popup...
Looks like there's a random srcdoc attribute being inserted into the inner iframe for the video stopping the iframe src from being called.
This is now done. Auto-adjusts size according to component width - not device width, so it will work on anything with space for it of 340px width regardless of what else is either side of the editor. There's a tabbing mode for coding and navigation for both accessibility and practicality, resetting, fullscreen mode and adjustable panel sizing. It's quicker than any code editor I've used, but then I'm just working offline and there isn't any syntax highlighting. It's 100% Active CSS, and only 3 custom ACSS commands, one to handle tabbing in code, and 2 to handle dragging a panel mover. Will sort out a separate repo next. Undoubtably I'll probably think of other things I can put in there as options, but it's good enough to go live. It won't work until 2.4.0 is released though, as it makes the most of the new component scoping and a bunch of other things. I'm trying really hard to get 2.4.0 done for xmas if I can, but my spidey-sense is still tingling re bugs so I'm reluctant to let loose yet. I'll be pushing my offline fixes live today though on the 2.4.0 branch, which fixes a whole lot of stuff.
The repo code is going to be two files. One ACSS file containing the HTML and all the events, and one CSS file that is linked from inside the shadow DOM of the component. Can't get simpler than that. Ultra-tweakable by the developer if they want.
Code editor repo:
https://github.com/Active-CSS/active-css-code-editor-component
I'm still tidying it up and will provide minified versions of the ACSS and CSS, but there it is.
Closing the issue.
The early versions of the docs website used a third-party editor for the examples. This was great, but there were some issues with auto-updating of examples (which may or may not be fixed now). But there was also the issue of having to set up all the examples which took ages and the UI being more complex than it needs to be for just playing around. And it wasn't instant response. Everybody likes instant response.
A better immediate solution is to write a drop-in iframe-based code editor that takes config in from a edit field and when "saved", re-runs the page. Putting the saved config, HTML and CSS into the inner iframe is ok, as it will be stored in the outer iframe and Active CSS can just insert it in there using the 'iframe -> body { render:""; }' syntax.
But doing this will make editing and playing around with examples really quick and cool. And it can be tied into the docs pre-rendering so that examples past and future will just work with it.
Just a run button should be enough. Maybe a copy button as well.
I'm not putting in auto-running, as it can get a bit annoying and it isn't totally relevant in an event-based system. When the person is ready, they can hit run.
Hitting refresh will reload the example. A temporary storage option could be added, but it isn't necessarily essential for playing around. It isn't supposed to be a development area - just a place to play around with the examples.
It will need to run in an iframe and be self-contained so that it doesn't inherit all the docs config settings and CSS and so that it can be inserted into anyone else's site if they want it. Shadow DOM won't cut it as it needs to be raw Active CSS for proper penning and so it reacts to all the Active CSS events including body:init. So it won't work fully as a component for what we want it to do.
The code for this will get it's own area in github, and a link will be put here for it.
It'll basically be a stripped-back codepen written in Active CSS and a bit of JavaScript.
It'll probably be a temporary move, so it's not going to be anything too fancy. It'll come in an NPM package too.