Awesome! I had the same idea on my todo list 😉

I was wondering if scroll_to would fit better in this context.

I was wondering if scroll_to would fit better in this context.

Maybe.

I have this idea that I would release a tutorial for a scroll_to custom operation that would support a lot more stuff:

• you can jump to a specific y pixel distance from the top
• you can control the scroll speed
• you can provide an easing function to the scroll
• you can provide a top-offset to respect top navigation bars when scrolling up

My main beef with scrollIntoView is that you can't "scroll to x", you can only "scroll at id".

Thank you for all of these proposals for new operations. I love it.

One convention that CableReady has adhered to "fairly well" that I'd like to formalize into a best practice is to ensure that operation names match as closely to the formal DOM API specification as possible. For example, if we use scrollIntoView in the internals, then the CR method should be scroll_into_view etc... I think that this naming convention provides the library with a few advantages.

1. Immediate grokability for people already familiar with the DOM
2. Principle of least surprise as to what the operation does and how it behaves
3. Retains maximum flexibility for extending the library with more operations (the hard work of naming things has generally been done for us)

That makes great sense, but there are important exceptions - I'm talking about graft.

https://indepth.dev/posts/1161/here-is-why-appendchild-moves-a-dom-node-between-parents

First, I hold up this article as evidence that most devs have no idea that they can use appendChild to graft an element and keep their Stimulus controllers intact. The primary use case in 2021 is not the same as it was when it was added to the API in the 90s.

Second, naming it append_child isn't great because it's not attempting to be a true wrapper for that function; appendChild has functionality for creating elements with supplied HTML and we don't even try to do that.

Third, I honestly believe that graft is both instructive and marketable. It's also shorter. 😸

there are important exceptions

I completely understand, which is why there's a proviso to violate the best practice for scenarios that don't map cleanly.

Having said that, I'm not sure graft fully communicates what's happening in that operation. Namely, that you're moving an existing element from one parent to another. Perhaps something like reparent more effectively communicates what's actually happening... granted it's not quite as punchy of a name.

More than just an awesome name.