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

Tidy up non-redoc extension presentation #847

Merged
merged 7 commits into from
Mar 15, 2019

Conversation

drjonnicholson
Copy link
Contributor

@drjonnicholson drjonnicholson commented Mar 14, 2019

This PR:

  • Standardises an extension to use the FieldLabel component rather than a bespoke one so the style matches
  • Removes the x- prefix from the extension when presenting the name on the page
  • Title cases the unprefixed extension name
  • Removes the extraneous " quotes from either side of the extension value, so strings like test are displayed as test and not "test"

Before:
image
(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:
image

@drjonnicholson
Copy link
Contributor Author

As an aside, I ran npm run prettier before making the commit to make sure it met code standards, and it changed a bunch of files

@@ -1,4 +1,9 @@
import * as React from 'react';

import { startCase } from 'lodash';
Copy link
Member

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

Copy link
Contributor

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.

Copy link
Member

@RomanHotsiy RomanHotsiy Mar 15, 2019

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.

Copy link
Contributor

@exoego exoego Mar 15, 2019

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.
image

Perhaps lodash dependencies should be replaced with more granular modules like lodash.set.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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

@RomanHotsiy
Copy link
Member

Also, add a screenshot of how it looks like now, please! That way it would be much easier for me.

Thanks in advance!

@drjonnicholson
Copy link
Contributor Author

@RomanGotsiy I've updated the PR description with before and after images

@RomanHotsiy
Copy link
Member

RomanHotsiy commented Mar 15, 2019

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!

@coveralls
Copy link

coveralls commented Mar 15, 2019

Coverage Status

Coverage increased (+0.03%) to 82.563% when pulling 44b3512 on drjonnicholson:master into 178ff4c on Rebilly:master.

@drjonnicholson
Copy link
Contributor Author

Good spot, so looking at default/exmaples, the : is inside the FieldLabel component, so that solves the vertical alignment issue.

There is also a horizontal issue in the value being closer to the label than it is to say an example. Here's a mocked up example:
image

I could either:

  • Leave as is
  • Reuse the existing ExampleValue styled component
  • Duplicate the ExampleValue component as ExtensionValue in field.ts, giving us a new extension hook etc.

Personally I like the duplication in this case - since it's initially duplicated but can be modified independently of examples etc, which serve a different purpose

I'm also tempted to remove the opacity of the Extension component. That sound good?

Any other changes while I'm at it? 😃

@RomanHotsiy
Copy link
Member

RomanHotsiy commented Mar 15, 2019

Personally I like the duplication in this case - since it's initially duplicated but can be modified independently of examples etc, which serve a different purpose

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.

I'm also tempted to remove the opacity of the Extension component. That sound good?

Yes, go ahead!

@drjonnicholson
Copy link
Contributor Author

Yeah that makes sense. Next commit going up, let me know if there's anything else under this PR you want done.

@drjonnicholson
Copy link
Contributor Author

Think that's everything. Output of Example against and Extension now looks like mock up (just tweaking he DOM a little to put them next to each other with same label value of Example:):

image

@RomanHotsiy RomanHotsiy merged commit b21cd3d into Redocly:master Mar 15, 2019
@RomanHotsiy
Copy link
Member

Looks awesome now! Thanks! 🙇

@RomanHotsiy
Copy link
Member

Just refactored it a bit dc77d8f.

Check it out please just in case.

@drjonnicholson
Copy link
Contributor Author

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 🙂

schof added a commit to mobileposse/ReDoc that referenced this pull request Mar 20, 2019
* 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)
  ...
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.

4 participants