Any plans to un-deprecate `DOMSideEffect` or bring...

# compose-web

[Big Chungus]

Any plans to un-deprecate DOMSideEffect or bring DOMScope to regular SideEffect? My use-case involves wrapping external JS component library in #kmdc project and I need an effect which runs on every composition and provides access to native DOM element to sync-up the compose state with the external JS component.
• DisposableEffect almost works as it has scopeElement, but it skips the initial composition
• SideEffect runs on all compositions, but doesn't provide access to scopeElement
• DOMSideEffect covers everything I need, but is deprecated
EDIT: looks like initial composition is "skipped" on my DisposableEffect handler due to missing js objects that I initialise in attrs::ref lambda. Shouldn't attrs::ref be invoked before DisposableEffect?

[Oleksandr Karpovich [JB]]

attr::ref is implemented as DisposableEffect itself. And it's added in the outer scope relatively to the content of an element.

something like:

Div {
DisposableEffect {...} // 1st
}
DisposableEffect { } // added for "ref", 2nd

After a quick look, I don't see any issue if try to force the order 1st-ref, 2nd-other effects. But I think it's worth checking it more carefully.
Could you please file an issue for this?

Maybe as a workaround for an order, DisposableEffect(Unit) can be used to initialise js objects

[Big Chungus]

Sure, I'll raise an issue. As for workarounds, I've already found a few, but none of them feel idiomatic 😄

My reasoning for ref order is that attrs are part of HTML Element's "metadata" and as such should be resolved before the content (i.e. inner DisposableEffect)

[Big Chungus]

Ideally I'd like to maintain the external JS component inside a composition local, but to initialise it I need the native DOM element, leaving me in a dependency loop 😄

[Big Chungus]

#2053