-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add RichTextEditor component #972
Conversation
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.
This is awesome. I left a bunch of comments, happy to chat or huddle to talk about them if needed
package.json
Outdated
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.
Can we get a sense of scale here? I imagine these extensions are pretty lightweight, but would like to confirm that we aren't increasing the size of our dependencies by an order of magnitude with this work
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 how to compare bundle size to be honest. How would you go about measuring that?
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.
https://www.npmjs.com/package/webpack-bundle-analyzer
You can see how it's implemented in RS here, though the implementation will be different as RS config is built from shaka: https://github.com/user-interviews/rails-server/blob/main/config/webpack/base.js#L117-L129
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.
Does the bundle size affect whether this PR can be merged?
We're already importing only the TipTap packages that we actually use so we wouldn't be able to build the same component with less dependencies.
This PR also blocks removing Plate, Slate and TipTap from RS so merging this PR will cause our overall bundle size to go down for the main repo.
Measuring bundle size for the DS is a great idea but I think editing our Webpack config is out of scope for this PR.
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 suggesting that you commit changes to our webpack config in this PR, but I think understanding the consequence of adding a new dependency is absolutely within scope of the PR that introduces it, and this one is adding 17. If you don't want to tinker with webpack to get this information, you can probably use something like https://bundlephobia.com/ to do the job. I don't know a ton about that site, I just did a little googling.
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.
According to Bundlephobia:
DS without TipTap
- 261.9 kB MIN
- 86.9 kB MIN + GZIP
DS with TipTap
- 600.6 kB MIN
- 217.8 kB MIN + GZIP
So between 2 to 2.5x the bundle size.
Slate and Plate dependencies in RS are:
- 679 kB MIN
- 203.4 kB MIN + GZIP
So the entire DS with TipTap is less or equal to just the size of our Plate/Slate dependencies that it allows us to get rid of.
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.
Awesome, thank you. This is exactly what I was hoping to confirm. If it were significantly larger than our deps before, it'd probably be something to give a little more thought before we double down on TipTap.
Just for clarity: does this data comparison includes the extensions for TipTap in addition to @tiptap/core
?
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 includes all TipTap packages we are using.
/** | ||
Callback function to call with sanitized HTML when editor state changes | ||
*/ | ||
onChange: propTypes.func.isRequired, |
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.
Do you think there'd be any value in providing other event callbacks to the props interface? onBlur, onFocus
, etc? It'd be trivial to add them down the line if when needed as well, but could be useful for validation handlers & error rendering
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.
This choice was less about value and more about shepherding devs towards what we use. I followed the other input components' lead on just having onChange. Everywhere I've seen we do validation handling and error rendering on change so this reenforces that. If we hit a use case where something really needs blur or focus callbacks I think we should add it then.
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.
Blur is commonly used to present any input errors if any are present. I think we should by default include it in any input component we add to the DS, even we don't use it (yet) in RS. error handling in the FE currently leaves a lot to be desired.
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 think we should by default include it in any input component we add to the DS, even we don't use it (yet) in RS.
I disagree with this. I think any new input component should have consistent event handlers with the existing input components.
I'm not opposed to adding onBlur
. onFocus
, etc. but I think if we do so they should be added to all of the input components within the same release.
You should be able to assume that all of the input components support the same event handlers.
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 don't feel strongly enough about this to press the point further, but I'd like to at least have an issue to address it with some corresponding breadcrumbs here eg // TODO DS-xyz: add blur event props
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 to me to add an issue to add more event handlers to our input components, including this one.
I think it makes more sense to include a checklist of those components in the issue, than to add a TODO
here, since we would want to add the new handlers to all of the input components to be consistent.
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.
As long as it's tracked and we are actively working to take care of it, I don't really care if there are TODO comments or not I suppose.
src/RichTextEditor/actionHandlers.js
Outdated
@@ -0,0 +1,33 @@ | |||
const hasNoHttpProtocol = (url) => url.indexOf('http://') !== 0 && url.indexOf('https://') !== 0; |
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.
We could probably use regex here to simplify this a bit if you'd like:
const hasNoHttpProtocol = (url) => !!url.match(/^http(s?):\/\//)
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.
Good call. I'll make this tweak.
src/RichTextEditor/actionHandlers.js
Outdated
return; | ||
} | ||
|
||
const absoluteUrl = hasNoHttpProtocol(url) ? `//${url}` : url; |
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.
this might be a bit more simple if we just define the regex here and use it, eg:
const protocolRegex = /^http(s?):\/\//;
const absoluteUrl = url.match(protocolRegex) ? url : `//${url}`;
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 made this change.
src/RichTextEditor/actionHandlers.js
Outdated
editor.chain().focus().extendMarkRange('link').setLink({ href: absoluteUrl }) | ||
.run(); |
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.
Nitpick: does this break line because of an EsLint rule? I typically like to break line for each function call once at least one break is required. I feel like they scan easier this way, eg:
editor
.chain()
.focus()
.extendMarkRange('link')
.setLink({ href: absoluteUrl })
.run();
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.
Yeah this was due to a linter rule. I'll make this tweak.
|
||
expect(screen.getByText('hello world')).toBeInTheDocument(); | ||
}); | ||
}); |
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.
Can we get some specs here to cover the supported actions? eg: bold, etc.
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.
Would you consider adding specs for the actions blocking?
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.
Either blocking or as a fast follow, yea. In my experience specs that aren't written with the code they cover often end up unwritten.
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'd prefer to add more tests as a fast follow. Merging this PR is blocking removing the old WYSIWYG from RS so I'd rather follow "fast beats perfect" in this case.
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.
That's fine with me, but please make sure that it does get tested.
label: 'Bold', | ||
name: RteActions.BOLD, | ||
disabled: availableActions.includes(RteActions.BOLD) && !editor.can() | ||
.chain() | ||
.focus() |
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.
We're doing something pretty similar in actionHandlers
. Is it possible to consolidate that & these calls to chain
, focus
, etc?
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 don't think we can consolidate them since its a method chain with a different method (can()
) at the beginning. Do you have something specific in mind?
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.
yea I think I do. Let me try and mess around with it tomorrow morning and offer a suggestion
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.
So, rather than having to run the same set of commands both here and in createActionHandlers
, I think it will be better to at the least co-locate the command sequence in createActionHandlers
, eg:
italic: {
onClick: () => editor.chain().focus().toggleItalic().run(),
disabled: !editor.can().toggleItalic(),
},
Then here in the component it'd just be:
{
label: 'Italic',
name: RichTextEditorActions.ITALIC,
disabled: actionHandlers.italic.disabled,
onClick: actionHandlers.italic.onClick,
icon: faItalic,
},
Also, what's the need for checking availableActions.includes(RichTextEditorActions.ITALIC)
in the disabled state? As far as I can tell, createActionHandlers
will always return an object keyed with link, unlink, bold, italic, unorderedList, orderedList
. Am I missing something or can this just be removed like in my pseudocode above?
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.
Also, what's the need for checking availableActions.includes(RichTextEditorActions.ITALIC) in the disabled state? As far as I can tell, createActionHandlers will always return an object keyed with link, unlink, bold, italic, unorderedList, orderedList. Am I missing something or can this just be removed like in my pseudocode above?
It can't be removed, or at least if it was there would need to be an alternative that serves the same need.
Only the extensions which correspond to availableActions
are initialized. Otherwise you would be able to use the keyboard shortcuts for extensions which aren't in the menu bar. That check is avoiding a null
error.
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.
ah yes I was conflating availableActions
with actionHandlers
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 doesn't make sense to me to move disabled
into createActionHandlers
because disabled
is only relevant to the menu bar (whether the button is disabled). createActionHandlers
is also used in RichTextEditor
when registering a keyboard shortcut for links.
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.
My primary suggestion here is to reduce the redundancy here. Without being co-located, drift between the two is much higher. Also it seems to me co-locating an event handler with a disabled state is perfectly reasonable, even if not all consumers of the data require it. Unless of course we're calling these tip tap actions in ways that aren't in response to user input, but that seems unlikely.
is also used in RichTextEditor when registering a keyboard shortcut for links.
Wouldn't we also want to register keyboard shortcuts if and only if editor.can()...
is true for the given action? Seems like we don't check that on links, is there a reason why some of these actions check if the command can be executed and others do not?
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.
Wouldn't we also want to register keyboard shortcuts if and only if editor.can()... is true for the given action?
I think you're conflating two concepts here. Keyboard shortcuts are registered on initialization. Just because they are initialized doesn't mean they are always available no matter what you're doing in the editor. For instance, you can't make text bold if you're currently within a code block. If you do CMD-B
inside a code block it still won't let you made the text bold. disabled
in this case is checking specifically if an action in the menu bar should be disabled because it currently is not allow based on where you are in the rich text in the editor. It fully has to do with the menu bar actions and not with the action handlers.
Seems like we don't check that on links, is there a reason why some of these actions check if the command can be executed and others do not?
We're registering a custom keyboard shortcut for links because a default isn't provided. The others have defaults. It is unrelated to the conversation above.
My primary suggestion here is to reduce the redundancy here. Without being co-located, drift between the two is much higher.
I get what you're saying, but I think putting the code in the place that relates to its purpose makes more sense than putting it next to similar looking code that is used for a different purpose. Moving it into actionHandlers
makes it look like disabled
has to do with how actions are handled when it really has to do with with whether a specific button in a specific place should be disabled.
I also don't think there is a high likelihood that we will change that code frequently since they are the exact method chains recommended by the docs. The only case I could see us changing it if is TipTap has a breaking change to their API, in which case we would want to vigilant about making changes anyway.
'RichTextEditor__field', | ||
{ 'RichTextEditor__field--error': hasErrors }, | ||
)} | ||
editor={editor} |
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.
Can we make this stronger somehow? I could be mistaken but it looks like we're allowing RichTextEditor
to essentially accept anything for props and pass it to EditorContent
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.
For better or worse ...rest
is a pretty common pattern in the design system. ...props
does the same and is even more common.
You're correct that it is passing along whatever props given that aren't used in this component.
In this case that is useful because you would want to pass down any ARIA attributes to the appropriate place.
What would you prefer?
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.
At the least, filtering the rest down to valid DOM props, or in this case I suppose valid props of EditorContent
.
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.
At the least, filtering the rest down to valid DOM props
As far as I know React doesn't differentiate between HTML attributes and props as far as passing them to child components. I'm not aware of a pattern to pass down HTML attributes but not props.
The main patterns I've seen for passing HTML attributes to child components are prop spreading and adding explicit props (such as ariaLabel
for aria-label
).
Explicit props are a pain because if the specific ARIA attribute you want to use isn't supported you just can't use it - which was actually a pain point with our old WYSIWYG component and affects accessibility. It would be quite an effort to add a prop for every possible ARIA attribute to all of our DS components.
or in this case I suppose valid props of EditorContent
TipTap actually supports this exact use-case the same way in EditorContent.
I know prop spreading is generally discouraged, but in the case of form elements that should be able to support any ARIA attribute it is probably the best option. And if we decide that it isn't then we should decide on an alternative for all DS components and have an effort to switch so that all of them are consistent.
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.
As far as I know React doesn't differentiate between HTML attributes and props
React will log a warning about an unsupported prop and recommend removing it: https://codesandbox.io/s/wispy-voice-vmddzn?file=/src/App.js
You can read an interesting conversation about why this is probably not a good thing to do here: https://gist.github.com/statianzo/91234d26094ad89c1ff742f41b25d737#gistcomment-1838594.
If we want to forward props from our component into the child, then I'd prefer we be explicit about it and use a prop eg editorContentProps
or if it's just for a11y then ariaProps: propTypes.shape({ // ...etc }}
and not spread literally anything and everything from RichTextEditor
into EditorContent
just to make aria props easier.
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.
React will log a warning about an unsupported prop and recommend removing it
For sure, and I agree that prop spreading should be avoided when it comes to passing down component specific props. The reason for it in this case is to be able to pass down ARIA attributes for accessibility. There are a lot of ARIA attributes so it wouldn't make sense to add a prop for each possible ARIA attribute. In this case I think the cost of devs having to be mindful of what props they pass is worth the reward of it being possible to provide any ARIA attribute when you need to for accessibility purposes.
You can read an interesting conversation about why this is probably not a good thing to do here: https://gist.github.com/statianzo/91234d26094ad89c1ff742f41b25d737#gistcomment-1838594.
I've read this discussion before and agree with it when it comes to passing props. It doesn't offer a better solution for passing HTML attributes such as ARIA attributes without explicitly providing a prop for each one.
If we want to forward props from our component into the child, then I'd prefer we be explicit about it and use a prop eg editorContentProps or if it's just for a11y then ariaProps: propTypes.shape({ // ...etc }} and not spread literally anything and everything from RichTextEditor into EditorContent just to make aria props easier.
What would the shape of ariaProps
look like that allows all ARIA attributes? Would we have to maintain a list of all possible ARIA attributes? I haven't been able to find a package that provides that and is actively maintained.
I realize prop spreading is a compromise here, and that in other situations it is a bad choice. In this case I don't see a better choice. This isn't being done to make passing down ARIA attributes easier it is being done to make passing down ARIA attributes possible.
It's totally possible there is a better solution to this problem. If so I think we should have a separate PR to move to that solution throughout the DS as opposed to blocking this PR.
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 doesn't offer a better solution
It actually does: use a named prop for the things we're forwarding and spread it instead:
const ContactBadgeBetter = ({ user, contactMethod, divProps }) => (
<div className='Badge' {...divProps} />
}
as opposed to
const ContactBadge = ({ user, contactMethod, ...rest }) => (
<div className='Badge' {...rest} />
}
This way at least, the props that are being forwarded are very intentional by separating the component’s props and the props you want to pass through. This helps prevent any consumer of the component from inadvertently forward things they don't intend to.
Down the line, it's not too hard to build a tool to filter invalid dom props. I've done it before. The html spec doesn't change that frequently but yea you'd be on the hook to keep it up to date. That updating could theoretically be done lazily, eg: when a dev is trying to forward a valid html prop but the filtered list is incorrect, but all of that is for another day and probably not worth it.
What would the shape of ariaProps look like that allows all ARIA attributes
Ideally yea it'd be exhaustive. But I'd settle for just propTypes.Object
if we can put these forwarded props into their own namespace.
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 made this change
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.
This is stellar and really excited to see this in here and used in other places in the app! ⭐ Left a few non-blocking suggestions to begin with, but otherwise looking really good.
## Props | ||
|
||
<ArgTypes of={RichTextEditor} /> |
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.
Could be good to expose the other stories in the MDX docs and any additional info that would be valuable for each of them.
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.
Great point. Added the other stories to the docs with more info.
font-size: 0.75rem; | ||
line-height: 1rem; |
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.
suggestion: could probably use font-type-20
here
min-height: 5rem; | ||
background: $ux-neutral-100; | ||
border: 1px solid $ux-gray-400; | ||
border-radius: 0.25rem; |
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.
suggestion: $ux-border-radius
className={classNames( | ||
className, | ||
'RichTextEditor__field', | ||
{ 'RichTextEditor__field--error': hasErrors }, |
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.
Just for my own curiosity, what would we be expecting for the error state? Would we be validating on character count (maybe empty char count?) or something else?
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.
Where this is currently used it is just being validated to not be empty.
variant="transparent" | ||
onClick={action.onClick} | ||
> | ||
<FontAwesomeIcon icon={action.icon} /> |
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.
Suggestion non-blocking: Wondering if we can make all of these icons the same width.
<FontAwesomeIcon className="fa-fw" icon={action.icon} />
Alternatively we do have the IconButton
component that does the same thing (though the common action
options don't currently include the icons for this RichTextEditor component but could be added via the icon
prop), but those icons probably wouldn't be used outside of the text editor most likely?
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.
Great call out. I was thinking about this before and wasn't sure which way to go.
(though the common action options don't currently include the icons for this RichTextEditor component but could be added via the icon prop), but those icons probably wouldn't be used outside of the text editor most likely?
This was my reasoning for not using IconButton
before.
After thinking about it a bit I went ahead and switched to IconButton
. I was basically recreating it, so it makes for these buttons to get any future updates to IconButton
like if we add hover tooltips in the future or something.
background-color: $ux-gray-100; | ||
border: 1px solid $ux-gray-400; | ||
border-bottom: 0; | ||
border-radius: 0.25rem 0.25rem 0 0; |
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.
$ux-border-radius
src/index.js
Outdated
AllRteActions, | ||
DefaultRteActions, | ||
RichTextEditor, | ||
RteActions, |
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.
Suggestion non-blocking:
Curious if it's possible to rename these to all start with Rte or RichTextEditor. Just thinking from an import perspective, I might not readily remember what is all available for the RichTextEditor, so by having it all start with the same name I can see what is available.
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.
Well, we definitely went back and forth quite a bit on some things here. I'm going to work on standardizing some expectations around prop spreading & html props, avoiding code repetition, what should be done when adding a new dependency, etc so they needn't be discussions on pull requests, but rather expectations as part of the work done.
Nice work
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.
Thanks for all the thought that went into this!
* add target to Alert action (#974) * Bump word-wrap from 1.2.3 to 1.2.4 (#976) Bumps [word-wrap](https://github.com/jonschlinkert/word-wrap) from 1.2.3 to 1.2.4. - [Release notes](https://github.com/jonschlinkert/word-wrap/releases) - [Commits](jonschlinkert/word-wrap@1.2.3...1.2.4) --- updated-dependencies: - dependency-name: word-wrap dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Bump semver from 5.7.1 to 5.7.2 (#967) Bumps [semver](https://github.com/npm/node-semver) from 5.7.1 to 5.7.2. - [Release notes](https://github.com/npm/node-semver/releases) - [Changelog](https://github.com/npm/node-semver/blob/v5.7.2/CHANGELOG.md) - [Commits](npm/node-semver@v5.7.1...v5.7.2) --- updated-dependencies: - dependency-name: semver dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Bump tough-cookie from 4.1.2 to 4.1.3 (#966) Bumps [tough-cookie](https://github.com/salesforce/tough-cookie) from 4.1.2 to 4.1.3. - [Release notes](https://github.com/salesforce/tough-cookie/releases) - [Changelog](https://github.com/salesforce/tough-cookie/blob/master/CHANGELOG.md) - [Commits](salesforce/tough-cookie@v4.1.2...v4.1.3) --- updated-dependencies: - dependency-name: tough-cookie dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Add RichTextEditor component (#972) Adds a RichTextEditor component to input and edit text with formatting. Currently supports bold, italic, link, unordered list, and ordered list.
* add unstyled variant to DropdownToggle (#704) * Merge release/1.33.0 into develop branch (#710) * add disabled ToggleInput story (#713) * Accordion updates for better content flexibility and alignment with Card (#708) * Merge release/1.34.0 into develop branch (#720) * Add label for Pill close button (#722) * remove prop spread on Accordion and ToggleInput, expose additional props as needed (#724) * update custom select Option to allow for indeterminate state on CheckboxButton (#727) * Merge release/1.34.1 into develop branch (#729) * CheckboxButtonGroup and RadioButtonGroup state and width updates (#731) * Merge release/1.34.2 into develop branch (#735) * Added ability to pass a `trailingIcon` to `ProfileCell` (#733) * Merge release/1.34.3 into develop branch (#741) * make modal prop work with all Selects (#743) * Fix color system JS variable order (#739) closes #738 Fixes the 500 level color values for green and navy. This is because the variables for 500 were used as the non-numbered values but those don't always correspond to the 500 value. I set them all to the 500 variables for consistency. * Merge release/1.35.0 into develop branch (#745) * Add aria-label for trailingIconOnClickSubmit Input (#751) * add Grid components (Container, Row, Col) (#750) * add Popover (proof of concept) (#717) * Merge release/1.36.0 into develop branch (#754) * change width to max-width on Card (#756) * Merge release/1.36.1 into develop branch (#758) * Use default color for input label tooltips (#761) * update cursor to pointer on select control (#765) * add CardStack (#763) * Merge release/1.36.2 into develop branch (#770) * Bump loader-utils from 1.4.0 to 1.4.1 (#775) Bumps [loader-utils](https://github.com/webpack/loader-utils) from 1.4.0 to 1.4.1. - [Release notes](https://github.com/webpack/loader-utils/releases) - [Changelog](https://github.com/webpack/loader-utils/blob/v1.4.1/CHANGELOG.md) - [Commits](webpack/loader-utils@v1.4.0...v1.4.1) --- updated-dependencies: - dependency-name: loader-utils dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * remove CardContainer and CardList (#772) * add OptionWithDescription for selects (#774) * Merge release/1.36.3 into develop branch (#779) * add Main layout component (#777) * add labelDescription to OptionWithDescription (#786) * add Flex component (#781) * Merge release/1.37.0 into develop branch (#788) * update TableCell compact variant to 0.75rem top padding (#793) * Bump loader-utils from 1.4.1 to 1.4.2 (#782) * add red Pill color (#790) * Add Text and Heading components (#785) * Merge release/1.38.0 into develop branch (#797) * add LoadingSkeleton (#800) * Adding contentCenterOverflow prop to LoadingOverlay (#802) * Merge release/1.38.1 into develop branch (#804) * import skeleton.css directly to LoadingSkeleton (#806) * Merge release/1.38.2 into develop branch (#808) * Adding optional props to Tabs component (#811) * Merge release/1.38.3 into develop branch (#813) * add Grouped Options story for SingleSelect (#816) * Bump express from 4.17.1 to 4.18.2 (#795) Bumps [express](https://github.com/expressjs/express) from 4.17.1 to 4.18.2. - [Release notes](https://github.com/expressjs/express/releases) - [Changelog](https://github.com/expressjs/express/blob/master/History.md) - [Commits](expressjs/express@4.17.1...4.18.2) --- updated-dependencies: - dependency-name: express dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Bump decode-uri-component from 0.2.0 to 0.2.2 (#794) Bumps [decode-uri-component](https://github.com/SamVerschueren/decode-uri-component) from 0.2.0 to 0.2.2. - [Release notes](https://github.com/SamVerschueren/decode-uri-component/releases) - [Commits](SamVerschueren/decode-uri-component@v0.2.0...v0.2.2) --- updated-dependencies: - dependency-name: decode-uri-component dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Bump qs from 6.5.2 to 6.5.3 (#791) Bumps [qs](https://github.com/ljharb/qs) from 6.5.2 to 6.5.3. - [Release notes](https://github.com/ljharb/qs/releases) - [Changelog](https://github.com/ljharb/qs/blob/main/CHANGELOG.md) - [Commits](ljharb/qs@v6.5.2...v6.5.3) --- updated-dependencies: - dependency-name: qs dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * some README cleanup (#817) * add pre-built loading skeleton to Card (#821) * Merge release/1.38.4 into develop branch (#823) * make inputId required on Select components (#827) * Bump http-cache-semantics from 4.1.0 to 4.1.1 (#828) Bumps [http-cache-semantics](https://github.com/kornelski/http-cache-semantics) from 4.1.0 to 4.1.1. - [Release notes](https://github.com/kornelski/http-cache-semantics/releases) - [Commits](kornelski/http-cache-semantics@v4.1.0...v4.1.1) --- updated-dependencies: - dependency-name: http-cache-semantics dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * export Main from DS (#831) * add loading state to Button (#833) * Merge release/1.39.0 into develop branch (#835) * set Button focus outline to only keyboard (#839) * Update setMessage to accept object in useToast.js and add Toast.mdx doc file (#838) Update setMessage in useToast.jsx to expect an object with message, title, action, and type keys and become order agnostic. Add Toast.mdx file with Props table and useToast documentation. * Merge release/1.40.0 into develop branch (#841) * Add bugsnag config to DS and handle toast arg error (#845) Add bugsnag configuration to DS in order to handle toast arg error. If users make a function call to useToast with the incorrect arg signature, it will trigger a bugsnag report. Eventually we hope to remove this error handling once we are confident we have correctly updated all use cases within rails-server. * use focus-visible for AccordionToggle focus state (#847) * update transparent button active bg color (#843) * add ProfileCellSkeleton (#825) * Merge release/1.41.0 into develop branch (#852) * Move react-scripts to devDependencies (#854) * enforce storybook v6.2.1 (#864) * Button height and typography updates (#849) * add conditional removeBorderLeft, update Alert padding (#858) * add conditional removeBorderLeft, update Alert padding (#858) * Revert "Button height and typography updates (#849)" (#873) This reverts commit 5fc8bfe. * upgrade to bugsnag 7 (#871) upgrade bugsnag JS to v7 and moved bugsnag to peerDependencies instead of top level dependencies * Merge release/1.41.1 into develop branch (#875) * button size updates (previously reverted) (#876) * Revert "button size updates (previously reverted) (#876)" (#880) * remove Bugsnag (#878) * Merge release/1.42.0 into develop branch (#882) * add TableLoadingSkeleton (#869) * update Input placeholder color to gray-700 (#866) * use UI logo for favicon (#884) * add DropdownDivider and destructive DropdownItem variant (#860) * Merge release/1.42.1 into develop branch (#886) * add fa-fw to DropdownItem (#890) * Improve outline transparent button disabled state (#894) closes #893 - Make `outline-transparent` disabled more obvious based on Veronica's design - Add `disabled` Button examples in Storybook * Merge release/1.42.2 into develop branch (#896) * Bug/746 fix asyncselect modal stories (#892) Fix Select > In Modal stories to add realistic modal behavior and fix annoying display issue * Add drawer component (#900) closes #897 Adds a `Drawer` component and corresponding `DrawerHeader`, `DrawerBody` and `DrawerFooter` child components. * upgrade Bootstrap 5.1 (#902) * Merge release/1.43.0 into develop branch (#904) * Drawer/Fix DrawerFooter onPrimaryAction click handler (#908) * Merge release/1.43.1 into develop branch (#910) * add Spacing stories to foundations (#914) * Improve Drawer breakpoints on tablets (#921) Closes #920 * The breakpoints weren't working as intended on tablet sized screens. Improved the media queries so when the screen size hits the width of the drawer the drawer becomes 100% width, for all size variants. * Switched to standard media queries instead of Bootstrap's mixin since we don't use it elsewhere * Storybook 7 upgrade (#911) * move btn-focus-outline--dark-bg to buttons styles (#917) * add TableFoot, update TableCell hover, and allow stickyRowBottom (#916) * bump node version max to 19 (#926) * remove unused react-scripts (#928) * Merge release/2.0.0-rc into develop branch (#932) * fix bad merge that included old SB6 duplicate docs (#934) * Merge release/2.0.0-rc1 into develop branch (#936) * Merge release/2.0.0 into develop branch (#938) * Add loading props to DrawerFooter actions (#942) 1. Add isLoading and loadingText props for primary and secondary actions 2. Make order of props and propTypes consistent * change Chromatic build deploy on main branch (#944) * add EmptyState component (#939) * Update module resolver to resolve dependabot (#945) * Merge release/2.0.1 into develop branch (#947) * Move deploy to GitHub actions (#950) * add MoneyInput component (#951) * add IconButton (#953) * Merge release/2.0.2 into develop branch (#955) * export IconButton (#957) * Merge release/2.0.3 into develop branch (#959) * add feature variant to Alert / Callout, unpublish announcement variant (#963) * Merge release/2.0.4 into develop branch (#965) * add target to Alert action (#974) * Bump word-wrap from 1.2.3 to 1.2.4 (#976) Bumps [word-wrap](https://github.com/jonschlinkert/word-wrap) from 1.2.3 to 1.2.4. - [Release notes](https://github.com/jonschlinkert/word-wrap/releases) - [Commits](jonschlinkert/word-wrap@1.2.3...1.2.4) --- updated-dependencies: - dependency-name: word-wrap dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Bump semver from 5.7.1 to 5.7.2 (#967) Bumps [semver](https://github.com/npm/node-semver) from 5.7.1 to 5.7.2. - [Release notes](https://github.com/npm/node-semver/releases) - [Changelog](https://github.com/npm/node-semver/blob/v5.7.2/CHANGELOG.md) - [Commits](npm/node-semver@v5.7.1...v5.7.2) --- updated-dependencies: - dependency-name: semver dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Bump tough-cookie from 4.1.2 to 4.1.3 (#966) Bumps [tough-cookie](https://github.com/salesforce/tough-cookie) from 4.1.2 to 4.1.3. - [Release notes](https://github.com/salesforce/tough-cookie/releases) - [Changelog](https://github.com/salesforce/tough-cookie/blob/master/CHANGELOG.md) - [Commits](salesforce/tough-cookie@v4.1.2...v4.1.3) --- updated-dependencies: - dependency-name: tough-cookie dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Add RichTextEditor component (#972) Adds a RichTextEditor component to input and edit text with formatting. Currently supports bold, italic, link, unordered list, and ordered list. * Merge release/2.1.0 into develop branch (#978) * upgrade FontAwesome v6.4.0 (#980) * ensure EmptyState title and subtitle have same margin-bottom (#984) * Adding lateral style icon and collapsed text (#986) * Merge release/2.1.1 into develop branch (#988) * Update issue templates (#995) * Create -ui-design-system--pr.md (#996) * uses yalc for linking the DS to RS (#1000) * Bump @adobe/css-tools from 4.2.0 to 4.3.1 (#989) Bumps [@adobe/css-tools](https://github.com/adobe/css-tools) from 4.2.0 to 4.3.1. - [Changelog](https://github.com/adobe/css-tools/blob/main/History.md) - [Commits](https://github.com/adobe/css-tools/commits) --- updated-dependencies: - dependency-name: "@adobe/css-tools" dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * upgrade storybook to 7.4.1 (#1005) * add TypeScript (#992) * add TypeScript packages * add tsconfig.json * update storybook/main.js * add preset-typescript to babelrc * add build-ts script * update tsconfig.json * add dummy TestPill component * Fixes up TS config (#993) * convert EmptyState to TS and remove demo TestPill * update EmptyStateProps * use relative import for Heading and Text in EmptyState * add react/jsx-filename-extension to .eslintrc * remove test copy * trailing comma * bring types/react-dom version down to ^16 --------- Co-authored-by: Kyle Shike <kyleshike@gmail.com> * upgrade dependencies for semver (#1010) * upgrade nodemon * upgrade eslint * remove eslint-import-resolver-webpack * try make-dir resolve to 3.1.0 * change make-dir to version 4 * update css-loader 4.3.0 * try semver resolutions * add normalize-package-data resolution to ^3.0.0 * add istanbul-lib-instrument resolution to ^6.0.0 * yarn.lock update post merge * add @babel/helper-create-regexp-features-plugin to resolutions * adds necessary final step for unlinking rs (#1011) * Merge release/2.2.0 into develop branch (#1015) * convert Heading component to TypeScript (#1017) * convert Flex component to TypeScript (#1018) * Migrates Tabs component to TS and CSS modules (#1038) * remove jest mock functions from stories (#1040) * Fixes storybook webpack config (#1042) * re-write components without styled-components (#1043) * Merge release/2.2.2 into develop branch (#1045) * upgrade css-loader (#1050) * Bump postcss from 8.4.29 to 8.4.31 (#1051) Bumps [postcss](https://github.com/postcss/postcss) from 8.4.29 to 8.4.31. - [Release notes](https://github.com/postcss/postcss/releases) - [Changelog](https://github.com/postcss/postcss/blob/main/CHANGELOG.md) - [Commits](postcss/postcss@8.4.29...8.4.31) --- updated-dependencies: - dependency-name: postcss dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Fixes Bootstrap classname collision in Tabs component for Rails Server (#1049) * Fixes prop name in Tabs (#1052) Prevents tab class name prop from getting overridden. * add trailingText to Input component (#1056) * Allow drawer to be expanded by default (#1057) * Merge release/2.2.3 into develop branch (#1059) * Bump postcss from 8.4.29 to 8.4.31 (#1060) Bumps [postcss](https://github.com/postcss/postcss) from 8.4.29 to 8.4.31. - [Release notes](https://github.com/postcss/postcss/releases) - [Changelog](https://github.com/postcss/postcss/blob/main/CHANGELOG.md) - [Commits](postcss/postcss@8.4.29...8.4.31) --- updated-dependencies: - dependency-name: postcss dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Use modal backdrop z index on drawer backdrop (#1063) * use Inter font (#1062) * FormGroup - update helper text, focus states (#1066) * remove window from Avatar classname (#1068) * add border to Card under Synthesized class (#1071) * Add Synthesis colors from Figma (#1069) * add pointer to CheckboxButton and RadioButton (#1074) * update Button to use Synthesis colors (#1076) * Implements Synthesis styles for tabs component (#1077) * Implements Synthesis styles for Select component (#1079) * Synthesize Alert / Toast colors (#1080) * Merge release/2.3.0 into develop branch (#1082) * FormGroup helperText prop type as node (#1087) * Merge release/2.3.1 into develop branch (#1089) * Bump @adobe/css-tools from 4.3.1 to 4.3.2 (#1085) * remove box shadow from MoneyInput, add step and prefix props (#1094) * update DropdownItem hover state, remove danger variant (#1091) * give default sizes to levels, make weight optional, add notes to props (#1096) * Merge release/2.4.0 into develop branch (#1099) * remove font-weight: 100 (#1102) * swap rem values for px values (#1104) * Adds template variables to RichTextEditor (#1105) * adds max height to template variable popup in RTE (#1106) * Fixes persistence of template vars (#1109) * Merge release/2.4.1 into develop branch (#1111) * update Toast dismiss timing (#1115) * Merge release/2.4.2 into develop branch (#1117) * add Synthesis spacing variables (#1123) * add warning and error tooltips (#1126) * Merge release/2.4.3 into develop branch (#1129) * add image support for EmptyState (#1132) * Merge release/2.4.4 into develop branch (#1134) * Converts RichTextEditor to TS, replaces templateVariables prop with customExtensions prop (#1121) * Convert Button to TS (#1138) * Merge release/2.5.0 into develop branch (#1142) * remove duplicate JS files RTE (#1143) * Prepare release 2.5.1 (#1145) * Prepare release 2.5.2 (#1147) * Merge release/2.5.2a into develop branch (#1149) * Allow prop type node for Card title (#1150) * Fix DropdownToggle focus color (#1154) Changes the styles to what we expected, which is that if you click the button to open the dropdown and then click it to close it the button goes back to the original color as opposed to staying the focused color * IconButton: expose loading props (#1152) * Bump ip from 2.0.0 to 2.0.1 (#1155) * Bump ip from 2.0.0 to 2.0.1 Bumps [ip](https://github.com/indutny/node-ip) from 2.0.0 to 2.0.1. - [Commits](indutny/node-ip@v2.0.0...v2.0.1) --- updated-dependencies: - dependency-name: ip dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> * Attempt to fix running specs * Update other actions to match new format --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Bob Saris <bob@userinterviews.com> * remove warning and danger Button variants from docs (#1158) * Disable drawer background scrolling if drawer has background overlay (#1156) * Merge release/2.6.0 into develop branch (#1162) * add forwardRef to DrawerBody (#1166) * Bump sanitize-html from 2.11.0 to 2.12.1 (#1163) * Bump webpack-dev-middleware from 6.1.1 to 6.1.2 (#1167) * Provides CSS properties for typography, layout and color (#1168) * Merge release/2.6.1 into develop branch (#1170) * Update RichTextEditor to be a forwardRef and expose setContent through useImperativeHandle (#1173) * Bump express from 4.18.2 to 4.19.2 (#1171) * Converts Card to typescript (#1160) * Merge release/2.7.0 into develop branch (#1175) * Fixes Card import resolution (#1176) * Merge release/2.7.1 into develop branch (#1178) * Removes knobs from Storybook stories (#1172) * Upgrade Storybook to v8.0.5 (#1179) * add tertiary Button variant (#1186) * Improves hover state of tabs to avoid content shifting (#1184) * Prepare release 2.7.2 (#1188) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> * Bump tar from 6.2.0 to 6.2.1 (#1183) Bumps [tar](https://github.com/isaacs/node-tar) from 6.2.0 to 6.2.1. - [Release notes](https://github.com/isaacs/node-tar/releases) - [Changelog](https://github.com/isaacs/node-tar/blob/main/CHANGELOG.md) - [Commits](isaacs/node-tar@v6.2.0...v6.2.1) --- updated-dependencies: - dependency-name: tar dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Updates FontAwesome peer deps (#1189) * remove non-synth colors, add borderedMultiValue styles SingleSelect (#1196) * Add default containerClassName to loading skeleton (#1195) * Merge release/2.8.0 into develop branch (#1201) * Merge release/3.0.0 into develop branch (#1216) Updates Node 20, React 18, Yarn 4 Removes the following which have been marked as deprecated: 1. Alert announcement type 2. Button danger and warning variants 3. DropdownToggle overrides of the above Button variants 4. Remove Sass vars represented as CSS Properties Also upgrades: - babel & storybook - font awesome - yarn - eslint and minor upgrades - react-dom - react-toggle --------- Co-authored-by: Kyle Shike <kyle.s@userinterviews.com> Co-authored-by: Jeff Baxendale <jeff@userinterviews.com> Co-authored-by: Gabe Scarbrough <gabe@userinterviews.com> * Show helper text in FormGroup regardless of error state (#1209) * Converts most of the components to TS (#1197) * fix checkbox button group Sass imports (#1217) * Update Tiptap to 2.3.1 (#1218) Updates Tiptap and its associated packages to the latest This is a minor version bump so there aren't breaking changes in the package's API Mostly getting bug fixes. Looking at their changelog there are some new features but I didn't see any changes to what we use. * Enable Dependabot Version Upgrades (#1219) Allows Dependabot to open up PRs with version upgrades, using a "widen" strategy by default which should be most compatible * Add DateTimePicker (#1220) Ports the DateTimePicker over from rails-server Converted to TypeScript and simplified the props a little bit in the process * Change Drawer expanded width to 90% (#1221) * Adds borderedMultiValue prop to Creatable select (#1222) * Adds responsive FlexContainer component (#1223) * Fix GH action to work with Yarn 4(#1229) * Prepare release v3.1.0 (#1231) Co-authored-by: GitHub Actions <41898282+github-actions[bot]@users.noreply.github.com> * Add async searchable multiSelect and searchable multiSelect types (#1228) * Fixes broken GH workflows (#1232) * Remove Drawer--open when drawer unmounts (#1227) * Remove Drawer--open when drawer unmounts * remove prop types * Prepare release v3.1.1 (#1234) Co-authored-by: GitHub Actions <41898282+github-actions[bot]@users.noreply.github.com> * Fix default props (#1235) * Prepare release v3.1.2 (#1237) Co-authored-by: GitHub Actions <41898282+github-actions[bot]@users.noreply.github.com> * Don't include css properties in theme (#1238) Mainly to keep the downstream misuse of this theme from breaking * Prepare release v3.1.3 (#1240) Co-authored-by: GitHub Actions <41898282+github-actions[bot]@users.noreply.github.com> * fixes class name redundancies (#1241) * Allow RichTextEditor to be read-only (#1243) * Merge release/v3.2.0 into develop branch (#1245) * Fix aria label on CreateableSelect (#1246) * Set RichTextEditor value to empty string if editor is empty (#1247) * Fix Heading default props & stories, fix disabled prop of CreateableSelect (#1248) * Merge release/v3.2.1 into develop branch (#1250) * Render disabled select option as disabled (#1252) * Merge release/v3.2.2 into develop branch (#1254) * fix button styles for active states (#1256) * upgrades some deps to address dependabot (#1257) * Prepare release v3.2.3 --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Jason Basuil <basuilj@gmail.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: brianCollinsUI <84730553+brianCollinsUI@users.noreply.github.com> Co-authored-by: TJ Barber <me@tjbarber.org> Co-authored-by: Gabe Scarbrough <gabescarbrough@gmail.com> Co-authored-by: Kyle Shike <kyleshike@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Dominik Schab <54962889+domschab23@users.noreply.github.com> Co-authored-by: Greta Hayes <greta@userinterviews.com> Co-authored-by: Gabe Scarbrough <gabe@userinterviews.com> Co-authored-by: Alex Dzwonchyk <alex.d@userinterviews.com> Co-authored-by: Devin Starks <DevStarks@gmail.com> Co-authored-by: Bob Saris <bob@userinterviews.com> Co-authored-by: Jane Sebastian <jane@userinterviews.com> Co-authored-by: Eric Xian <eric2523@gmail.com> Co-authored-by: Kyle Shike <kyle.s@userinterviews.com> Co-authored-by: Jeff Baxendale <jeff@userinterviews.com> Co-authored-by: Jeff Baxendale <jeffbax@users.noreply.github.com> Co-authored-by: Oceane <31403932+magicmarie@users.noreply.github.com> Co-authored-by: Jack Lieblich <jacklieb220@gmail.com>
closes #970
Adds a
RichTextEditor
component to input and edit text with formatting. Currently supports bold, italic, link, unordered list, and ordered list.Built on top of TipTap which supports easily adding further actions including custom extensions. See the nodes, marks and extensions sections of their docs for existing extensions.
Chromatic: https://www.chromatic.com/build?appId=62d040e741710e4f085e0647&number=255