Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@khamer
Copy link
Contributor

@khamer khamer commented Sep 24, 2021

This is a minor change that, when generating labels for components, uses the original case version of name instead of the lowercased version. This means having component folder names like someComponent/ correctly become Some Component, whereas without this change, it becomes Somecomponent.

Copy link
Member

@mihkeleidast mihkeleidast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this change at all. name is documented as such: "values must be all lowercase, and contain only alphanumeric characters with hyphens or underscores for word seperators".

Is there a reason for using camelCase instead of kebab-case for naming files/folders?

@khamer
Copy link
Contributor Author

khamer commented Sep 27, 2021

Yes - the files themselves are also being referenced by the CMS (Craft) by slug, and those slugs need to be alphanumeric identifiers (no dashes.)

I will update doc.js too, I don't see anything in the Doc class's _label method that would require access to the whole config object.

Maybe a better question is - what does this hurt? I believe it just improves the the label generation, but doesn't change what files Fractal looks at, handles, etc.

@khamer
Copy link
Contributor Author

khamer commented Oct 5, 2021

I updated doc.js to work with this change. I believe the config.label check might be redundant to what's being done in entity.js's initEntity, but I left it, it won't hurt anything being there.

Again - we're using fractal with twig files we're sharing with another system where slugs can't contain dashes, and while everything works as is, this change makes the labels shown in Fractal show up "Like This" instead of "Likethis" by default. I looked for a way to override the _label method via a collection config file, but I don't think that's possible, and you're already using titlize() - it's just sending the original name to titlize() instead of a lowercased one.

@mihkeleidast
Copy link
Member

Thanks for this. I'll try to find time to take a look at this again sometime this week. It needs a bit of manual testing, since I don't believe these parts of the codebase are covered by any tests.

@mihkeleidast mihkeleidast changed the title Don't lowercase name before titlizing to generate label fix: don't lowercase name before titlizing to generate label Nov 4, 2021
@mihkeleidast
Copy link
Member

mihkeleidast commented Nov 4, 2021

Thanks, looks good! Sorry for the delay, forgot this :) I'll try to get this merged once GitHub Actions starts working properly again.

@mihkeleidast
Copy link
Member

@khamer I have no idea why GitHub doesn't allow me to run the workflows or merge main in to fix the out-of-dateness. Would you mind filing the PR again? Thanks.

@khamer
Copy link
Contributor Author

khamer commented Nov 4, 2021

@mihkeleidast Sure, but if you'd like, check this one once more - I pulled all the subsequent upstream commits to my fork, so it might let you merge cleanly now. If not, I'll just make a new PR.

@mihkeleidast
Copy link
Member

Oh cool, the "Approve and Run" button appeared now!

@mihkeleidast
Copy link
Member

@khamer do you have any idea why the diff isn't clean? 🤔

@khamer
Copy link
Contributor Author

khamer commented Nov 5, 2021

Hrm, I'm not, but reset my main branch to upstream and cherrypicked just my two commits and now the diff looks clean, and files changed on github shows the right two instead of twelve.

@mihkeleidast
Copy link
Member

Thanks, looks good now!

@mihkeleidast mihkeleidast merged commit daf5c69 into frctl:main Nov 6, 2021
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 this pull request may close these issues.

2 participants