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

Why dasherize adds a leading dash? #23

Open
sporto opened this issue Oct 17, 2017 · 7 comments · May be fixed by #57
Open

Why dasherize adds a leading dash? #23

sporto opened this issue Oct 17, 2017 · 7 comments · May be fixed by #57

Comments

@sporto
Copy link
Contributor

sporto commented Oct 17, 2017

underscore "SomeClassName" == "some_class_name"

Doesn't add _ at the beginning.

dasherize "SomeClassName" == "-some-class-name"

Adds leading _.

What is the logic for this. Seems unexpected.

@jaapz
Copy link
Collaborator

jaapz commented Oct 19, 2017

I agree this is weird. However this functionality is based on underscore.string, and they actually specify it to work like this in their docs: http://epeli.github.io/underscore.string/#dasherize-string-gt-string

I can see this being useful in their documented use case (special css properties). However I can also see a usecase for what you describe.

Maybe we should change the default behaviour to do what you describe, and add a flag "addInitialDash" or something like that, to keep the initial dash functionality accessible. This will however be an API break, so we'd have to release a major version for this.

@lorenzo what do you think?

@sporto
Copy link
Contributor Author

sporto commented Oct 19, 2017

I see, thanks for answering. The use case they show for css properties is very specific. I don't think this library should to that as is not the general behaviour you would expect. If you want a leading dash then is trivial to add a prefix later.

@lorenzo
Copy link
Collaborator

lorenzo commented Oct 20, 2017

@sporto can you send a PR fixing this?

@jaapz
Copy link
Collaborator

jaapz commented Oct 20, 2017

I would also be okay with just removing the initial dash and have the user add it themselves later, however I think we should make sure to mention that when releasing it as a major version

@ianmackenzie
Copy link
Contributor

One potential approach for versioning: add the new behavior as hyphenate or hyphenated (I prefer the former but the latter is consistent with underscored), deprecate dasherize and then remove it in the next major release. Avoids silently breaking any code (dasherize behavior stays the same until it is removed, at which point anyone still using it will get a compile error), and allows use of the new functionality right away without having to immediately do a major version bump.

@sporto
Copy link
Contributor Author

sporto commented Oct 21, 2017

@lorenzo I'll be happy to make a PR.

Re alternative name to avoid major version. Making a major version change seems like a big deal, I struggle with this in my libraries. But since using Elm I'm getting more comfortable with doing major version changes for seemingly small things, but still feels heavy. Up to you.

@lorenzo
Copy link
Collaborator

lorenzo commented Oct 23, 2017

I'm ok with a new major version

cllns added a commit to cllns/elm-string-extra that referenced this issue Mar 15, 2023
cllns added a commit to cllns/elm-string-extra that referenced this issue Mar 15, 2023
@cllns cllns linked a pull request Mar 15, 2023 that will close this issue
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

Successfully merging a pull request may close this issue.

4 participants