Remove

[carrenelloyd]

Catalog # 18

Link to Design

View remove implementation

This may have working code, check with Vikki Paterson.

Maintainer Vikki Paterson

Tasks

• [x] Initial review of design/existing code

Working in experimental package

• [x] Create a shell component which
  • [x] Create ComponentName/ComponentName.js component file that renders props in raw form (no styling or sub components, plain text OK)
  • [x] Adds prop-types with comments for DocGen to ComponentName/ComponentName.js
  • [x] Add Doc file e.g. ComponentName.mdx with a brief description of the component.
• [x] First engineering review/playback

Continuing in experimental package

• [x] Storybook - stories to cover design scenarios, story with long, min and max content, etc
• [x] Doc tab in storybook derived from design docs with embedded stories where appropriate
• [x] Code to include prop-types with comments for automated DocGen documentation
• [x] Tests (written in React Test Library) to cover behavior from the documented in the components mdx file.

Review and promote

• [ ] Design review
• [ ] Add design review issues addressed, issues raised or discounted.
• [ ] Engineering review - Submit PR to promote component to production package
• [ ] All engineering issues addressed, issues raised or discounted.

[lee-chase]

@vikkipaterson can you comment as to the status of the design it was set to 'status: refining' by @carrenelloyd

[lee-chase]

Still need to add stories and tests

[davidmenendez]

Initial development has been completed for the RemovalModal and all prerequisites listed above have been satisfied. I think this is ready for review.

[davidmenendez]

@vikkipaterson @carrenelloyd this component is ready for a design review

[chloepoulterdesign]

Issue 1

On High impact the modal is a "remove" but the button says "delete". This is actually the case for a few of them - wherever Remove is used, it should be used in all places, and vice versa with Delete. This also needs to be consistent in the "post delete" modals.

Issue 2

With the high-impact variations, can we set the field label to be Type [name of resource] to confirm?

Issue 3

There is also no placeholder text in the field (there is in the designs) - but this is not stop-ship.

Issue 4

It's not clear to people that the same component can be repurposed for use in a "delete" action. We should either:

• replace all instances of "remove" and "delete" with "Remove/Delete" so that people can choose as appropriate
• create an identical ide delete component that exclusively uses "delete" in all locations.

[vikkipaterson]

Issue 1 There shouldn't be an high impact version of remove. High impact is only applicable to delete, whereas remove has the medium or low varieties so the high impact ones should only reference Delete, not remove.

Issue 2 Can we change the default text in the high impact modal to be clearer in reflecting the purpose of it. The high impact modal requires the user to manually type in the name of the resource as confirmation to enable the deletion of it. The example text should highlight the consequences of deleting (name of the resource) as well as stating the action can't be undone. The label of the textbox should be instructional as to what they need to type into it to be able to confirm the deletion. e.g. Type [name of resource] to confirm

This is a screen shot of the design in the pattern

[davidmenendez]

@chloepoulterdesign @vikkipaterson thanks for the feedback. i'll take care of this ASAP.

[davidmenendez]

@chloepoulterdesign @vikkipaterson upon further inspection of your feedback I think you may have been looking at the IdeRemove component, which is the old component. The new one is called RemovalModal. Some of the feedback provided was still applicable to the new component I worked on, but the screenshot indicates you were looking at the previous component. Here's the new component. The content should be updated as soon as my latest pull request is merged in https://ibm-cloud-cognitive.netlify.app/?path=/story/experimental-removalmodal--without-confirmation

[davidmenendez]

@chloepoulterdesign @vikkipaterson the stories have been updated. please take another look at the with confirmation and without confirmation stories under Experimental/RemovalModal

[Levinson1]

@chloepoulterdesign can you provide a final review before the end of the week?

[chloepoulterdesign]

Looks good to me. If it is at all possible, it would be great to rename the component to RemoveDeleteModal to make it clear it can be used for either, but otherwise, LGTM!

[lee-chase]

It would appear @davidmenendez that if you rename to RemoveDeleteModal the Chloe is happy to move this into 'Release Review' state.

[davidmenendez]

fantastic. i'll get this done today 👍

[sydrosa]

Review for release

Readiness

• [x] One or more scenarios for a design pattern have been identified as a useful unit of functionality to publish.
• [x] A functioning component or components delivering those scenarios have been delivered and merged to master.
• [x] Design maintainer has approved the implementation for those scenarios (via a comment on the relevant issue/epic).

Engineering review

• [x] Breaking changes have only been introduced with prior approval, discussion and documented in release notes. Ideally deprecation notices in the prior major version must have been added in a timely fashion.
• [x] The implementation takes into account, and does not impair, remaining and anticipated design scenarios.
• [ ] Public component features (names, props, etc) are consistent with Carbon-defined conventions and are consistent internally. Where there isn't an existing convention to apply, ensure robust precedents are being established. -- Issue 751
• [x] The UI produced is accessible, responsive, translatable, cross-browser, and responds to the currently set Carbon theme.
• [x] Components are functional components using hooks.
• [x] Public components which produce DOM structures support className.
• [x] Public components support a ref (via React.forwardRef).
• [x] All significant DOM elements have meaningful classes.
• [x] Additional attributes that are not identified as props (such as title, aria-*, etc) are passed through to an appropriate DOM node of the component as HTML attributes.
• [x] No warnings, errors or log messages in the console.
• [x] Each public component JS is exported in /src/components/index.js, each public component SCSS is included in /src/components/_index.scss, and each public component has a flag in package-settings.js.

Standards

• [x] No linter warnings or errors are produced.
• [x] Carbon tokens (theme, layout, motion) are used unless the design specifies otherwise.
• [x] Code is formatted according to prettier rules (no use of //prettier-ignore).
• [x] Code is clear, maintainable and follows standard React practices and the code guidelines.
• [ ] Copyright header in every source file (js, css, scss etc.) with the appropriate years. -- Issue 751

Testing

• [x] There is a set of test cases for the components.
• [ ] The tests exercise all inputs (props, slots, etc) and verify appropriate outputs. -- Issue 751
• [ ] The tests validate the behaviors and interactions defined in the design where practical. -- Issue 751
• [x] The tests achieve 100% coverage. Usage of istanbul ignore is appropriate and not extensive.
• [x] No warnings, errors or log messages in the test output.

Documentation

• [x] Source code is satisfactorily commented and provides DocGen comments for all public components and their props.
• [x] There is a story for each design scenario. The stories expose all relevant props and actions, and additional usage documentation and code samples are available on the 'Docs' tab along with the props table.
• [ ] There is a sandbox (or multiple sandboxes if appropriate) on CodeSandbox for the components. -- Issue 751