how to reset wires?

[atirip]

I have a problem where I need to reset all wires to be able to rerender content:

I am building HTML editor, where I have a sidebar that allows modifying elements. That sidebar is collected every time from different components that are applyable of currently editable element. First time everything works fine, lets say editing Image Element. But then, lets say editing Button Element, everything in hyperHTML breaks down - as it desperately tries to carefully patch the contents of the sidebar and get's lost. So far the only way to get it render properly is to ditch wireid's and patch hyperHTML to try catch numerous crashes in various remove and append functions. Of course I did that only the be able to render something and this is not a solution, as while editing I do need to rerender that sidebar by changing only changed stuff. I guess there is some way to reset all weak maps associated with wires?

[atirip]

Ah, was digging under wrong tree. This simple function added and exported solves my problem:

    var reset = function(props) {
      wires.delete(props);
    }

Would you like to add it permanently?

[WebReflection]

hyperHTML is very stable, so unless you provide a minimal example that shows how it breaks, it's hard to understand your issue.

Wires are also weak references, to have new wires you just pass new objects instead of previous one.

I think you are wiring same objects in various places, which you can't, as documented, 'cause you need to use the wire(ref, id) in such case, but again, I won't do anything until I'm able to validate any issue,

Thanks for helping me helping you.

[atirip]

But of course, sometimes one is just blind, just cloning my this.props does the same.

[WebReflection]

there's not a single line of code here, I am going to close this issue.

[atirip]

Sorry, I just have no time right now to extract that one from the codebase and make render independently. Either I may try to give you private access to what we are building (and even that is not slam dunk) or I will do some summary article in my dusty blog after we have shipped. There are quite a lot of issues that will bite newcomers hard as when domdiff gets confused, it just crashes with hard to debug and cryptic errors. I think by now I know most of them and are able to avoid, but still, the most frustrating is that the same kind of crashes happen on different kind of errors - returning different stuff in ifelse (either wire or empty literal for example), repeating wireid’s (it is sometimes challenging to generate and manage all these id’s when your renderer contains tens of subroutines) and this issue, when I just had wildly mixed content of the same basic components on every rerender. To clarify this case - I do keep this.props in my components intact, changing only properties and then passing it to all wires, this way everything works as a magic, unless it does not and then one needs to create a new ( i just clone it ) to do fresh render without trying to diff the dom. All this is something that should be in the docs or best practices, but it isn’t. I try to help you with documenting these cases after we have shipped.

[WebReflection]

Sorry, I just have no time right now to extract that one from the codebase and make render independently

Sorry but I just have no time for imagining issues neither

do some summary article in my dusty blog after we have shipped.

please don't, 'cause you stated stuff like "it desperately tries to carefully patch the contents of the sidebar and get's lost" which is not what our production code has ever done, and we have fairly complex components, handling hundred thousand items of data runtime.

So, if you want to understand what you are doing wrong, or you want me to fix any bug, I need to see examples, code, all the usual things any useful filed bug would require in any SoftWare project.

There are quite a lot of issues that will bite newcomers hard as when domdiff gets confused

Nobody using hyperHTML should ever care about domdiff, there is a documentation, and rules.

Stick to those rules and everything works. File bugs with rants instead of examples, and nothing will change.

the most frustrating is that the same kind of crashes happen on different kind of errors

There are various projects out there based on hyperHTML and you are the only one so far so frustrated.

Yet I haven't seen a single example of yours that would show failures.

it is sometimes challenging to generate and manage all these id’s when your renderer contains tens of subroutines

You can skip that altogether and use one-off wires, or you can swap to lighterhtml and see how that goes, since it was born to simplify wires handling, which is done automatically for you.

hyperHTML gives you more control but if you have difficulties in controlling it, then it's not the right tool for you.

this way everything works as a magic, unless it does not and then one needs to create a new ( i just clone it ) to do fresh render without trying to diff the dom

If you interfere with the DOM manually, a DOM owned by hyperHTML, you are the cause of your own pain.

Don't even ever use node.textContent = '' in the wild, 'cause that would break, the same as it would break in any other famous framework if you don't let them handle their own stuff.

All this is something that should be in the docs or best practices, but it isn’t.

It isn't because it's the worst practice. You never need to do what you are doing. I don't ever need to do that, and I deal with million users daily consuming complex components that handle thousand data (but I'm repeating myself here, sorry).

I try to help you with documenting these cases after we have shipped.

That's better than this ticket full of rants and zero help so I welcome that, but it looks upside down to me, 'cause maybe I tell you an easy way to fix all your issues and you don't have to waste more time helping me with documenting failures, neither answering me in here 👋

[atirip]

You seem unnecessary tense, I am not ranting, this is just feedback. I extracted some code and generated codepen for you, if you have interest some time (click on 'button', 'email', 'input' to render stuff). There are comments inside JS for you (search //AG). Main questions are:

• line 1114, why it works the way it works? not obvious at all
• line 960, this really is IMHO nowhere mentioned in the rules

PS! My last message was honestly intended to finish discussion with this issue of mine, your attack was a bad surprise.

[WebReflection]

I didn't want to attack, but I am a full time employee and I have literally no time to read long discussions where there's absolutely nothing actionable.

At least now there is eventually something I can read at, and I'll be happy, whenever I'll find the time, to have a look into your thousand+ lines of code.

Best Regards.