Active-CSS / active-css

The epic event-driven browser language for UI with functionality in one-liner CSS. Over 100 incredible CSS commands for DOM manipulation, ajax, reactive variables, single-page application routing, and lots more. Could CSS be the JavaScript framework of the future?
https://activecss.org
Other
42 stars 7 forks source link

host attribute not available below componentOpen event in an ACSS strictly component #191

Closed bob2517 closed 2 years ago

bob2517 commented 2 years ago

Workaround is to assign a var in beforeComponentOpen, but this needs fixing.

bob2517 commented 2 years ago

Also, "host < form" isn't working as expected from inside a component. It looks like "host < anything" isn't working. Should be a quick fix.

bob2517 commented 2 years ago

Currently there are 3 selector evaluation methods in the core - the ideal would be to have only one which handles all scenarios. You should be able to do this on any target selector and for action commands that use a selector:

host < host div > p {
}

document -> div iframe -> #div p {
}

All three target scenarios that are incomplete according to the current docs and implemented at different times for handling different purposes. Consolidation is the next thing.

First things is to get target selectors working fully. That should give us a full working function. Then implement the same on the action commands and then decommission the old functions. The end result should either be to return a single item or an element collection with associated reference variables.

bob2517 commented 2 years ago

The most working function is _prepSelector, which mostly handles the '<' aspect of selectors. Start with that one and build up.

bob2517 commented 2 years ago

Note that this is made even more complicated because variables need to get evaluated in their correct scope as used in selectors.

I think it's simplest and probably most intuitive if variables get evaluated from the event selector object/target selector object or component that they get called from. Anything more than that for variables and it's going to get weird. A decision needs to be made as to which variable applies. The one in the target area or the one in the existing component. It's going to have to be the one in the existing component. The developer is thinking "in" the component they are working on. If something else happens after that, then there would need to be a trigger from the end target selector, or the ability to have nested target selectors (interesting idea that isn't yet implemented - don't do it yet!).

Currently evaluation happens after target selectors are located. This is the wrong sequence - variables in a target selector string need to be evaluated prior to selector evaluation (_spltIframeEls in _performTarget stuff).

Scoping needs to be given due care.

bob2517 commented 2 years ago

This is a mini project, but nailing this will make all the selectors stable wherever they are used. At the moment it's a bit hit or miss whether something is going to work or not, as I found out recently and was like "huh?".

bob2517 commented 2 years ago

I'm going to leave this for the moment unless someone asks for it. I need a full weekend to attack it and I can get a quicker kill on a different issue.

bob2517 commented 2 years ago

Looking at this with other issues completed, it actually looks a bit easier than I thought. All the selector functions are related and linked up to do different things. It just needs some refactoring and further separation to tie together more accurately.

bob2517 commented 2 years ago

The original fix target of this issue should actually be a quick fix - it's actually only "out" in a couple of places, but I'm going to review this area anyway so that I'm certain that really complex selectors are allowed.

bob2517 commented 2 years ago

Making good progress on this - a little bit more consolidation of functionality is still required though. It's not too far off though.

bob2517 commented 2 years ago

All the selector grabbing is now consolidated into one place, and all the tests I've done so far are now working properly. Everything on the docs site works as expected. I found an area to optimise, which has speeded up the general event flow too. The good thing is that any errors in the area of selector handling, like using iframe references, "<" handling for closest element, etc., when fixed (if they exist), will be a global fix. All target selector referencing and action commands that have selectors now all go through the same code to get the selector result. That was really important to consolidate, as it will be trivial-ish to fix selector errors if they appear now.

Just a bit of clean-up to do and testing of the original issue and this issue should be ready for the release.

This should be a fully backward compatible fix, but code should be tested regardless as this was a refactoring of the event flow as well as a selector grabbing rewrite.

bob2517 commented 2 years ago

Original issue fixed offline. WIll commit shortly.

bob2517 commented 2 years ago

Just optimizing something on this... will have a commit within the hour.

bob2517 commented 2 years ago

Closing in preparation for release.