rsm-hcd / andculturecode.javascript.react.components Goto Github PK

Where does the sketchpad component belong in this folder structure? I'm assuming this is considered an atom or is it considered molecule? How do we differentiate the two? The current sketchpad component is rendering a <div/> with two containing <canvas/> elements. I'm also assuming this would be considered a form component and therefore belong in a/the forms folder?

• accessible-list
• cards
• dropdown-button
• error-banner
• form-fields / checkbox-form-field
• form-fields / input-form-field
• form-fields / password-form-field
• form-fields / select-form-field
• form-fields / text-area-form-field
• form
• radio-list
• tooltips
• unordered-list

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

By defining font-sizes, margins, padding, etc as REMs and EMs instead of pixels, we can create a much more responsive system by default and makes it easier to proportionately size items relative to their context.

For example, sizing an icon in a button to 1em height and width means it automatically scales up and down based on the size of the button's text and doesn't need to be explicitly defined for each variation. Also, by strategically using REM vs EMs, we can make it really easy to proportionally scale up or down all pieces of a children component, making them much more flexible automatically.

This proposal would include defining a base unit size at the body level (eg 16px), then replacing every instance of px units throughout the rest of the stylesheets to use REMs or EMs according to that base size.

https://share.getcloudapp.com/mXuAe18Z

Feature request

What is the expected behavior?
To have the default branch named main instead of master

What is motivation or use case for adding/changing the behavior?
Removing terminology in technology evocative of racial inequality.

How should this be implemented in your opinion?
Following Scott Hanselman's advice

1. Move master to main (maintains branch history)

git branch -m master main
git push -u origin main

2. Update the default branch in repo settings from master to main.
3. Repoint HEAD, and delete master branch.

git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
git push origin --delete master

Are you willing to work on this yourself?
no

Per @joshuapeters suggestion in PR #48

It would be great if we could do that for the other stylesheets so that if a file is moved it doesn't regress a ton of components (a big bonus for the global stylesheet)

It looks like you can define module aliases in webpack for all things in general. See here for reference.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Similar to #90, I'm proposing we merge the various form-field molecules into a single component with the ability to specify the field type. They are all using the same class and stylesheet, as well as have lots of overlapping functionality that would benefit from consolidation.

This is related to #86 because the components in the form-fields folder in molecules need to remain together since they are using the same stylesheet. I don't want to break them up into their own folders and duplicate the styles if we are just going to be merging them anyway.

Currently there is only a single default props "render-style" test

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Currently there is only a single default props "render-style" test

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

In previous component libraries or projects I've worked on, I've found it helpful to set a rule that the lowest level components (in our case, Atoms) should only consist of a single HTML tag and that the styles for that component use the tag selector instead of a class. For example, the label component would be composed of a single <label> tag and it's css selection is handled like label { ... }. This helps defer complexity to higher layers in the structure, and the lowered specificity can be helpful when styling children in larger components.

Currently, we have a mix of this practice and the c-component class pattern. For example, the anchor Atom is selected with a { ... } while button applies a .c-button { ... } selection.

The one possible exception to this rule is icons, because there is no dedicated HTML tag for them. Perhaps there are other cases where Atom class names would need to be used to disambiguate two or more distinctly unique component implementations of the same base HTML tag.

I'd suggest that if we implement this change, it happens after #84, since that update would see a number of components currently classified as Atoms move to the Molecule layer where they would retain their class name.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

• ToastManager
• ToastTemplates

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

In further defining our standards/patterns around atomic design it really should be married with static analysis tooling to keep us in check. That for folks to bend the rules, they must explicitly call it out (ie. lint rules, rules of hooks, etc...)

Just like we need the use of C# analyzers on the backend to maintain the integrity of the layers of the onion, we need that here to accompany the documentation.

Note: This issue has to be worked on by an andculture employee since the styles will be ported from an internal project.

The knobs for Dropdown button are not working in storybook. The button size and button style knobs are not reflected in the rendering of the dropdown when their values are changed. The styles can be ported from the fire/electrical codes project.

I built a pretty robust icon system for the redesign of Anthm that was never completed. I'd like to replace the current icon collection with this set. It would add consistency to the sizing and style of the icons in this library, as well as significantly increase the total number of icons available with a total count of 60 icons.

Here's a sample of what they look like:

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Currently there is only a single default props "render-style" test

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

As defined in the docs, Atoms are supposed to be a single "component" (I'm assuming this means HTML tag). This also implies that an Atom cannot contain another Atom, and any component that does contain an Atom is at least a Molecule.

There are numerous components currently classified as Atoms that, by this definition, are actually Molecules. I propose moving them to the Molecules layer.

atoms/*/anchor-with-icon.tsx => span element. Anchor and Icon components.
atoms/*/checkbox-button.tsx => label, span, and input elements. Icon component.
atoms/*/checkbox-input.tsx => label, input, and span elements
atoms/*/radio-button-input.tsx => div, input, and label elements
atoms/*/select.tsx => div, and select elements. Icon component.
atoms/*/text-input-icon.tsx => div element. Icon and TextInput components.
atoms/*/progress-bar.tsx => 2 div elements.
atoms/*/toast-templates.tsx => 3 div elements. Icon component.
atoms/*/heading-icon.tsx => div element. Icon and Heading components.

When implementing this sketchpad, click functionality can be removed from all elements outside of the sketchpad.

Because baseUrl is defined as ./src in the tsconfig.json file, editors like VSCode will automatically import modules relative to that path instead of relative to their location.

In a normal project setting, this would be preferred - it cleans up the import pathing, and we know we're always going to be importing from under src anyway.

Nothing appears to be wrong when you're working in the context of this project, but when the Typescript is compiled down to plain JS, the imports get mucked up and modules won't resolve correctly. See rsm-hcd/AndcultureCode.JavaScript.Core#17 for an example of this.

We should remove this setting and verify the project still runs/builds as expected.

Currently there is only a single default props "render-style" test

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Similar to moving scss files into component folders, I think we should consider moving component-specific interface/utility files into the component folder. It aligns with our goal of keeping component files together and allowing them to be more self-contained.

Related to #86, but not explicitly documented there, so I wanted to break it out as a separate issue.

Port over the react-quill editor from client project. Depends on utlities being ported to AndcultureCode/AndcultureCode.JavaScript.Quill. See rsm-hcd/AndcultureCode.JavaScript.Quill#1.

I propose we merge all form input Atoms into a single input Atom that includes a type property to differentiate between types. By merging all of these into a single component, we can handle shared functionality a lot more efficiently and keep things a little more DRY.

For example, I merged text-input-icon into text-input as part of #84, but the password-input component doesn't have the same icon functionality. To add it, we'd have to duplicate over the parts of the text-input component and any changes in the future would have to be done in both places. Multiply this once we add things like Date/Numbers/Email/File input types and we have a ton of work to make any small changes to these components.

Our components also more closely resemble their base HTML counterparts, making it more intuitive from a consumer viewpoint.

At this point, the only existing components that would be affected would be password-input and text-input but this change would allow us to use the same component for all input types, meaning we get a lot more functionality than we currently have.

We could also merge in the textarea component for simplicities sake (by adding a type="textarea" option and conditionally rendering a textarea element instead of an input element if type matches. I'm on the fence about this since it does go back on the close ties to their HTML counterparts, but it still reduces some duplication.

Currently there is only a single default props "render-style" test

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Gather all design resources required, create collection of github issues under the "Apply Melody Designs" github project

Resources:

• Invision: https://andculture.invisionapp.com/d/main#/projects/prototypes/13112332
• TODO: Get complete set of design files that can be shared publically (pending)

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Currently there is only a single default props "render-style" test

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Pulled in this component for a small personal project and I noticed it was setting the -invalid classname by default. Looks like it is controlled by the isValid prop, but it feels like maybe that shouldn't be something controlled from its own prop - the presence of errorMessage or errorMesssages props might make more sense. At the very least, "invalid" should not be the default state (if it's a nullable prop and I don't know I need to pass it, it shouldn't be invalid)

Consider the following...

https://levelup.gitconnected.com/adding-state-to-storybook-in-react-c6744fda25b4

I tried adding the above in my branch but didn't have any luck persisting state across renders. Not sure why. I didn't spend a lot of time on it. Regardless, something like this would be helpful to easily lift state up to handle controlled components so interactions can be easily wired up and put on display in Storybook.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

There are a few components that have a separate version of the same component with the addition of an icon. I propose that those get merged with the base component so that it has an optional icon property that can be passed in. If it isn't null, an icon is rendered. This would help standardize components so the same patterns can be found across components, simplify the component search/selection process, and make our components more customizable and robust.

anchor-with-icon.tsx would be merged into anchor.tsx
button.tsx would be extended to include an icon prop instead of inserting an Icon component as a child
text-input-icon.tsx would be merged into text-input.tsx
heading-icon.tsx would be merged into heading.tsx

While many components are organized this way, the notable exception is the forms folder. A button component has its own folder, yet almost a dozen components share the forms folder. By giving each component its own named folder, it eases organization, maintainability, and portability since components are self-contained and isolated from each other.

I think there could be some exceptions to this rule. Perhaps if two or more components are very similar to each other, use the same base styles, and were only kept separate to avoid bloated prop objects or over-abstraction, then they could share a folder. An example of this might be the input components (text-input, password-input, etc).

On the other hand, if we did keep this as a strict rule and forced somewhat similar - but still distinct - components to have separate folders, then we could abstract out their shared visual styles into mixins which could then be reused in other situations as well.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Currently there is only a single default props "render-style" test

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Extension methods provided by jest are not being found when writing assertions

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Using other component tests as a guide, write automated tests to cover important scenarios in component. Try to avoid granular assertions of the markup. Stay as high-level as possible to avoid test fragility.

Problem
Currently, need to determine best way to wrap DropdownButton in proper context

Error:

Cannot read property '_context' of undefined
TypeError: Cannot read property '_context' of undefined
    at useContext (http://localhost:6006/vendors~main.2ce84569679e01c89ee7.bundle.js:262746:17)
    at useDescendants (http://localhost:6006/vendors~main.2ce84569679e01c89ee7.bundle.js:3645:66)
    at Menu (http://localhost:6006/vendors~main.2ce84569679e01c89ee7.bundle.js:4001:98)
    at renderWithHooks (http://localhost:6006/vendors~main.2ce84569679e01c89ee7.bundle.js:241891:18)
    at mountIndeterminateComponent (http://localhost:6006/vendors~main.2ce84569679e01c89ee7.bundle.js:244425:13)
    at beginWork$1 (http://localhost:6006/vendors~main.2ce84569679e01c89ee7.bundle.js:245787:16)
    at HTMLUnknownElement.callCallback (http://localhost:6006/vendors~main.2ce84569679e01c89ee7.bundle.js:225986:14)
    at Object.invokeGuardedCallbackDev (http://localhost:6006/vendors~main.2ce84569679e01c89ee7.bundle.js:226035:16)
    at invokeGuardedCallback (http://localhost:6006/vendors~main.2ce84569679e01c89ee7.bundle.js:226090:31)
    at beginWork$$1 (http://localhost:6006/vendors~main.2ce84569679e01c89ee7.bundle.js:251388:7)