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 with camelCase and all caps inputs. #39

Open
jacobrussell opened this issue Jan 18, 2023 · 0 comments
Open

Bug with camelCase and all caps inputs. #39

jacobrussell opened this issue Jan 18, 2023 · 0 comments

Comments

@jacobrussell
Copy link

jacobrussell commented Jan 18, 2023

What is this feature about (expected vs actual behaviour)?

The camel case filter, in this used via a Craft CMS filter that I'm told (by the CMS developer) directly uses Stringy, appears to return unexpected results in the case of an all caps input. The CMS appears to provide no additional processing to Stringy's return, so it appears to be a transparent layer in this issue.

Input - 'FOO BAR'
Expected Output - 'fooBar'
Actual Output - 'fOOBAR'

I haven't been able to find a strict definition for how came case should behave when applied to an all caps source, but in testing with several web-based tools (found in a 'camel case text' google search) all return my expected output. Stringy (again via a Craft CMS filter) returns the output in 'Actual Output'.

How can I reproduce it?

Add a case to your test suite with an all caps input.

Does it take minutes, hours or days to fix?

Probably minutes, easy answer would be to push all letters to lower case before camel casing (this was the workaround I used in my implementation).

Any additional information?

I could be wrong about the 'correct' implementation of camel case, but anecdotal evidence makes me believe I'm not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant