Create context select methods

[markelog]

i.e so methods like selectNodesByType would be exist on other types of entities.

Even though they can be slow, it could be terribly useful.

[Smolations]

I had the same request, so I'm glad there is an issue for it already. I also had a couple of other questions:

• Why .insertChildBefore() but no .insertChildAfter()?
• Why does .removeChild() return the removed element, but .removeChildren() does not return the removed elements?
• Why can you only .replaceChildren() with a single element instead of allowing an array of elements?
• There are various .get*Token() methods, but none to get whitespace tokens (i'm finding myself needing a method like that as I'm adding lines to code while trying to match indentations, etc.). Any particular reason?

In a project I'm working on, I've created a util object to help with some common element selection operations that are not already included on an Element. These may be something others would also find helpful to be included in the native API:

// searches the entire tree for the first occurrence of a type; this
// was useful for picking out array expressions that i knew only
// occurred once in a file. slow for large csts, but useful in my case.
function deepSearchForType(element, type) {}

// self-explanatory?
function findChildrenByType(element, type) {}
function findFirstChildOfType(element, type) {}
function findLastChildOfType(element, type) {}

[markelog]

Looks inconsistent right? Heh, that's because we choose familiarity instead of consistency. Familiarity? You ask, yes Familiarity with DOM API.

It also doesn't have insertChildAfter, that's why signature of replaceChildren looks like this and removeChildren is our method which doesn't exist in DOM, so we probably can change their return, especially considering that we still in 0.x version state. If you could create a ticket for this that would be cool.

There are various .get*Token() methods...
Any particular reason?

Nope, just we didn't had a need for it, could be okay addition though, could you create a ticket for this too?

These may be something others would also find helpful to be included in the native API:

Could you make it as standalone project first? Like https://github.com/Yeti-or/cst-helpers. Pretty sure that would be helpful! We need to realise what kind of API we should have. It seems we need a basics stuff first so people could augment on top of it.

Like native Promises vs Bluebird or DOM API vs jQuery, kinda like that i think

[Smolations]

Thanks for the reply! I will definitely check that project out.

When you say "create a ticket," do you mean to create a single issue with a single request (as opposed to this issue, which bundles several suggestions together)?

[markelog]

When you say "create a ticket," do you mean to create a single issue with a single request (as opposed to this issue, which bundles several suggestions together)?

Yeah, usually one bug/feature one ticket approach is easy to manage