-
-
Notifications
You must be signed in to change notification settings - Fork 925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there a bug with dynamically changing svgs? #2886
Comments
@EverettMcKay Can you provide a sample code in flems that shows this? |
I tried to come up with a simplified version of what I am doing:
The only problem: this sample code works exactly as expected. I will need to spend some quality time to figure out how my code is different. (I fully expected this to repro the problem.) In the meantime, any tips on how to figure this out would be greatly appreciated. |
This is almost certainly a keying issue — try passing a unique key to each div in your map, right next to style & onclick. |
Thanks Scott. I am definitely using keys and it's the first thing I tried. My keys look like this:
Where i is the index of the icon in the array, icon determines the svg to display, and state is the current user input that this is based on. You would think that would cover all bases. The console trace shows that these keys are exactly as expected. Unfortunately, the browser Elements tab doesn't show keys in the markup. Here is the overall structure of how I am using the keys (in the actual code):
So, the key is where you would expect it. (Right?) |
mmm. Try creating a unique id field for the actual source objects and just use that. Relying on array index is a footgun. Sent from my iPhoneOn Oct 8, 2023, at 11:45 AM, EverettMcKay ***@***.***> wrote:
Thanks Scott. I am definitely using keys and it's the first thing I tried. My keys look like this:
key = key${i}-${icon}-${state)};
Where i is the index of the icon in the array, icon determines the svg to display, and state is the current user input that this is based on. You would think that would cover all bases.
The console trace shows that these keys are exactly as expected. Unfortunately, the browser Elements tab doesn't show keys in the markup.
Here is the overall structure of how I am using the keys (in the actual code):
<div style={getIconStyle(xxx)} key={key} onclick=(handler is here) >
<div style={backgroundStyle}>{getIcon(xxx)}</div>
</div>
So, the key is where you would expect it. (Right?)
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
I'm not sure what to do, then. I have an array of 5 icons, 1 - 5. So, the index is the best way to distinguish them. Icon 1 is always icon 1, etc. Upon further testing, I've noticed something that might help: The bug boils down to that fact that no matter which icon I click on, icon 5 is the one that gets updated. So, if I click on icon 1, the key is right, the icon is right, but for some reason icon 5 is the one that changes. So, at least icon 5 works... I've tried different keys (and have confirmed are different and change when the state changes) and even removing the keys, but the result is always the same. So, for whatever reason, the DOM change is happening to the last icon in the array. |
Use the option name as your key. In your simplified code, that would be If the key is the object identity, add such a property (can just be an ID counter or symbol) that can be used as a property key (Mithril tracks them as property keys internally). Edit: elaborate |
Thanks, Claudia. I understand the general case, but in this specific case, the option names are literally 1 - 5. (The options are used to give a 1 - 5 score.) |
If it's always returning the last item in the array then check to make sure your view is not iterating over the icons and always returning the last event handler. Or the event handler code uses the correct icon identifier. Personally I found it helps to simplify the logic in the view and move that complexity into the closure of the component / into a shared file if needed. |
@EverettMcKay Then those are the names to plug into your If that's not working, you'll need to share code that reproduces the problem. |
Since the easy attempt to repro the problem (above) didn't work, I will need to add more to it until the problem appears. But I would like to explore one last idea: If the problem were key related, I'm pretty sure I would have solved it long ago. I am not able to repro the problem with my existing code if I'm not using svgs. So, if replace < svg >[some icon]< /svg > with < p >{ Seems like an important clue that I don't know what to do with (and my reason for the title question.) |
That's just a sign you probably need keys. I still want to see self-contained code that repros your problem, though. (And this search also helps tremendously in figuring out if it's a bug in your code or a bug in the framework.) Also, I have a sneaking suspicion you may be getting bit by whatwg/html#5484 (title says iframes, but it also impacts animations). Try seeing if using a shadow DOM works per whatwg/html#5484 (comment) - if so, then that's most certainly your issue. |
A quick update: I need to support email HTML (which is a bit dodgy and doesn't always support svg tags), so I changed the code to this:
In this case, everything works as expected when the target is email. I have many reasons to prefer using the svgs, but this test again confirms that it's an svg refresh problem. |
I spent a few more hours on this today to try different approaches. All failed. Again, the problem is that for svgs, the shadow dom isn't properly refreshing propertly when you change an SVG dynamically. |
Could you post an example that doesn't work so that we may toy with it too? Here's a flems with your previous example converted to plain |
I have an array of numbers (assume 1 - 5) that is mapped to svgs for display. When the user clicks on a number, the svg changes . However, the wrong svg is often updated (so, clicking on 3 will update the svg for 5 instead of 3).
I suspect this is a mithril svg update problem. Here's why:
I've tried hacking the key for the containing div, but that appears to make no difference.
Is this a known problem? Is there a work around?
I am using the current versions of Chrome and Edge.
The text was updated successfully, but these errors were encountered: