Skip to content
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

[Bug] Component key is sometimes a string and sometimes an int #727

Open
2 tasks done
gsxdsm opened this issue Aug 14, 2024 · 1 comment
Open
2 tasks done

[Bug] Component key is sometimes a string and sometimes an int #727

gsxdsm opened this issue Aug 14, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@gsxdsm
Copy link

gsxdsm commented Aug 14, 2024

Bug Description

The "key" for a component when passed in through a template is usually passed in as a number, however when a component gets deserialized from a server call it is parsed as a string. This causes sporadic bugs with method calls when you pass in a component key as the target.

Expected behaviour

Component keys should always be a string or a number - or the comparison for key lookup in unicorn.js could use type coercion -

  if (_component.key === componentNameOrKey) {
    component = _component;
  }

  if (_component.key == componentNameOrKey) {
    component = _component;
  }

But that seems a bit hacky.

Screenshots / Screenrecords

N/A

Steps to reproduce

No response

What browsers are you seeing the problem on?

Chrome

👀 Have you checked for similar open issues?

  • I checked and didn't find similar issue

Code of Conduct

  • I agree to follow this project's Code of Conduct

Are you willing to work on this issue ?

No, someone else can work on it

@gsxdsm
Copy link
Author

gsxdsm commented Aug 15, 2024

Actually, doing the type coercion is JS seems to be the best approach. Opened PR - #728

I considered casting the key to a string in the templatetag, however this means that you will always have to remember to wrap the key var in the JS with quotes - ex: Unicorn.call('{{mykey}}', 'function') vs Unicorn.call({{mykey}}, 'function') and could break existing code. Letting JS do the type coercion is the cleanest approach and there doesn't seem to be much risk in this type coercion always happening (ex: when would two unique components have the same key value but of different types? Seems impossible).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant