-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Tidy up non-redoc extension presentation #847
Conversation
As an aside, I ran |
src/components/Fields/Extensions.tsx
Outdated
@@ -1,4 +1,9 @@ | |||
import * as React from 'react'; | |||
|
|||
import { startCase } from 'lodash'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a point to pull in lodash because of the only startCase
function?
Could you implement a simple one yourself e.g. in utils
or just copy lodash's one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you afraid of importing single function ?
I don't think it is good idea to re-invent (or copy) common functions already defined in libralies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not about importing a single function. It's about adding a new dependency as lodash
is not in the dependencies yet.
The main reasoning behind this is the bundle size. While it doesn't matter so much for node apps it matters for browsers. Tree-shaking isn't perfect. I just tested and importing this single function leads to 68KB! increase in bundle size. Don't you find it too much for such a simple function (especially since vendor extension names can't contain any special Unicode symbols).
Hope this does make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense 👍
Looks like lodash
are not used in production code right now, so importing single function may add 68KB
or around to bundle.
Perhaps lodash
dependencies should be replaced with more granular modules like lodash.set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but this is development code so it doesn't matter so much and I don't think it's worth to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @RomanGotsiy and @exoego, thanks for having a look at this.
So I agree with @exoego to avoid reinventing the wheel etc where possible, but 68k bundle increase is too big for a quite simple function. I'm ultimately happy with switching this out to something more appropriate. Happy with what you guys decide really.
There was a problem hiding this 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 now if we need to title-case the extension name at all.
Vendor extension can contain arbitrary name so e.g.: x-Some Title
is a valid extension. So you have a workaround to show title-cased labels but if we title case them by default other users don't have a way to display lower-case label.
Summing up, I think we should remove startCase
at all. Do you agree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point, if x-Some Title
is valid then yeah completely agree - we can't guess or impose one method of presentation over another.
And I can solve my use case by just capitalising the first letter after the x-
prefix, so I'm happy.
I'll update the PR in a moment
Also, add a screenshot of how it looks like now, please! That way it would be much easier for me. Thanks in advance! |
@RomanGotsiy I've updated the PR description with before and after images |
Thanks! While you're already on it. Could you plz also check text vertical alignment issue (check on the screenshot) 🙇 If you can't fix it in 10-15 mins, leave it for me! |
Can you try extending just extending it? i.e. export const ExtensionValue = styled(ExampleValue)`` No extra extension hook though but it can be added later if needed.
Yes, go ahead! |
Yeah that makes sense. Next commit going up, let me know if there's anything else under this PR you want done. |
Looks awesome now! Thanks! 🙇 |
Just refactored it a bit dc77d8f. Check it out please just in case. |
Nice change. I imagine Inspecting the type must be faster than string manipulation. Feel bad I didn’t think of that approach! Thanks for making a great product all, and for making submitting improvements a welcoming experience 🙂 |
* master: (73 commits) chore: fixes typo in error message for detecting a circular dependency in theme.ts (Redocly#852) chore: minor refactor fix: tidy up non-redoc vendor extension presentation (Redocly#847) chore(cli): redoc-cli v0.8.3 fix(cli): add node-libs-browser to the deps chore(cli): redoc-cli v0.8.2 fix: fix redoc-cli broken dependencies chore: Release 2.0.0-rc.4 🔖 feat: display requestBody description Redocly#833 (Redocly#838) fix: move swagger2openapi to deps because of missing transitive deps chore(cli): redoc-cli v0.8.0 chore: update peerDeps before release chore: Release 2.0.0-rc.3 🔖 fix: add extra deref step for anyOf/oneOf variants chore: Remove duplicate re-export from index.ts (Redocly#842) fix: pin lunr version in ReDoc chore: fix cli declarations feat: support externalValue for examples chore: update deps docs: Fixed docker README, added missing redocly repo name (Redocly#841) ...
This PR:
FieldLabel
component rather than a bespoke one so the style matchesx-
prefix from the extension when presenting the name on the page"
quotes from either side of the extension value, so strings liketest
are displayed astest
and not"test"
Before:
(where we're using
x-scope
to annotate the scope required for a particular field to be populated from our API above and beyond the scope needed to access the endpoint itself, which is defined in security objects etc)After: