More than just an awesome name.

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.

I also am testing on Firefox 84.0.2.

I apologize. I thought I had seen web_sys::window() return None inside Firefox but Crash on Chrome. But when I tried to create a minimal example of that just now, I could not. I am getting the same results as you (crashes on Firefox also.)

Here is a small example that reproduces this issue: https://github.com/dhandy2013/web-sys-issue-2272

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. 😸

FYI as this issue is recent, I'm just learning and wanted to use WASI in the browser with WasmerJS, and have managed to make use of wasm-bindgen to simplify handling of bindings.

Reading the above I wonder what will and won't work with this approach. I've been collecting examples using wasm-bindgen to probe the limits but there aren't many out there. The ones I found in the wasm-bindgen book are incomplete and I'm not sure if my failure to get them working is my lack of understanding or because the issues mentioned above (e.g. see this issue).

Pointers to more examples welcome, and if you are interested in using WasmerJS with wasm-bindgen, or have comments that will help me understand the usefulness of this approach let me know. The demo project is: https://github.com/happybeing/svelte-wasi-with-rust

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)

• Move configuration to main namespace
• Use process wide singleton for config
• Use thread singleton for Channels
• Eliminates the cyclical dependency between Channel and Channels
• Tightens security around broadcast contexts
• Addresses multi-threaded broadcast race conditions
• ⚠️ Will likely force a major version bump

CableReady::Config.instance   # returns a singleton (state shared by all threads)
CableReady::Channels.instance # returns a thread local singleton (no shared state)

Custom operations can be added like so (at any time of the application lifecycle):

CableReady.configure do |config|
  config.add_operation_name :custom_magic
end

See the full example of how to use custom operations.

Note that StimulusReflex users will need to wait for https://github.com/hopsoft/stimulus_reflex/pull/421 before they can use custom operations via the cable_ready helper method in their reflexes.

@dhandy2013 I've just tested in Firefox 84.0.2 and still get an exception. maybe that's something on your side?

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

Is https://adodson.com/notification.js/ a possible solution for Notification?

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

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

The PR came to me in a dream.

The graft operation makes it possible to transplant one or several elements from their initial location in the DOM hierarchy and append them to a new parent container element. This is exciting because you can perform this action and not lose the internal state of any Stimulus controllers on the target element or its children.

The operation is cancelable and acceptsparent and focus_selector keys. parent is a CSS query that matches a single DOM element; if no element is returned, the operation is aborted.

This PR proposes to add an operation which wraps https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView

Additional information: web_sys::window() properly returns None in a worker thread on FireFox. It only crashes for me when running on the Chrome browser. So there is a browser compatibility issue here - the Window global is defined in JavaScript on Firefox when running a Web Worker, but on Chrome/Chromium it apparently is undefined.