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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] does ARRAY_ERROR and FORM_ERROR have to be Symbols? #106

Closed
Andarist opened this issue Apr 10, 2018 · 6 comments
Closed

[question] does ARRAY_ERROR and FORM_ERROR have to be Symbols? #106

Andarist opened this issue Apr 10, 2018 · 6 comments
Assignees

Comments

@Andarist
Copy link
Contributor

This is causing me some serious headache when dealing with non es6+ browsers (ie11 馃槶) and I'm wondering what's the use case for those? Couldnt they easily be replaced with non-symbols?

@erikras
Copy link
Member

erikras commented Apr 11, 2018

The idea, and I think this is mostly the whole point of symbols, is to avoid namespace collision. They could be a string, but that would make a field name invalid.

Are polyfills not sufficient to alleviate your suffering?

@Andarist
Copy link
Contributor Author

The idea, and I think this is mostly the whole point of symbols, is to avoid namespace collision. They could be a string, but that would make a field name invalid.

Many libraries use some distinct strings for it - in fact context names in legacy context API even couldnt be symbols so strings were enforce. I understand it's not ideal, because name clash is possible, but I think smth like @@final-form/ARRAY_ERROR would be "good enough" and universal.

My use case is pretty niche, but we distribute an installable widget and parts of its code is executed on our customers' website where I cannot just install global polyfill because it might cause numerous unexpected results for them so we avoid it at all costs.

Also this polyfill costs 3kb~ (from what i remember, ive checked it yesterday) which could be avoided.

I understand though that u might not want to migrate off this, as community we probably should start to support more and more es6+ by default, unfortunately on a global market we cannot ship it by default, because our customers expect it to work in IE11, some sandboxed windows "smart clients" (which use IE11 engine under the hood) etc - so overally im torn between wanting to support them and also wanting to finally use newer stuff.

Also I've finally debugged my issue to the core and at least I know what happened - after I have polyfilled Symbols (because final-form required this) I've ended up with other issue in redux because of that. If you are interested (quick read) you might see my redux PR (with explanation what happened) here.

@erikras
Copy link
Member

erikras commented Apr 11, 2018

Okay. You've convinced me. 馃憤

@ghost ghost assigned erikras Apr 11, 2018
@ghost ghost added the in progress label Apr 11, 2018
@ghost ghost removed the in progress label Apr 11, 2018
@Andarist
Copy link
Contributor Author

Thanks! 馃槏

@erikras
Copy link
Member

erikras commented Apr 11, 2018

Published fix in v4.5.1.

@lock
Copy link

lock bot commented Apr 11, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Apr 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants