web-wallet: Refactor CSS for Operation Component to Fully Adhere to BEM Conventions

[nortonandreev]

Refactor CSS for Send Component to Enforce Strict BEM Conventions & Consistency with Stake

Background

The Send component currently uses a loosely BEM-inspired naming scheme (e.g. .operation__send, .operation__address-wrapper, etc.). However, it does not strictly follow BEM conventions. In our architecture, both Send and Stake are concrete implementations of a higher-level Operation. This means that as much of the markup as possible—along with the class names—should be identical between them for consistency and maintainability.

Goals

• Strict BEM Conformance: Refactor the Send component’s CSS to strictly adhere to the block__element--modifier pattern.
• Consistency Across Implementations: Ensure that shared markup and class names are consistent between Send and Stake. This allows us to treat them as variations of a high-level Operation, with shared structure and styling.
• Reduce Global Overrides: Minimize the use of :global selectors and deeply nested selectors to improve maintainability and prevent naming conflicts.

Issues & Examples

1. Block Naming & Hierarchy

   • Issue: The Send component is implemented under a block called operation, but the component itself is Send. This can cause confusion when sharing markup with the Stake component.
   • Recommendation: Adopt the high-level operation block for shared elements. For instance, use a common class (e.g. .operation__content or .operation__body) instead of component-specific names like .operation__send.
   • Example:

     - <div class="operation__send">...</div>
     + <div class="operation__content">...</div>

     This naming convention can then be reused in the Stake component for a unified structure.

2. Consistent Element Naming

   • Issue: There are discrepancies in element names. For example, we have:
     • .operation__address-wrapper (for the address section)
     • .review-transaction__label and .review-transaction__value (for the review section)
   • Recommendation: Standardize element names under the operation block so that both Send and Stake share the same markup.
   • Example:

     - .operation__address-wrapper { ... }
     + .operation__address { ... }

     - .review-transaction__label { ... }
     + .operation__review-label { ... }

     This ensures that both components use the same class names for the same elements.

3. Modifier Usage

   • Issue: Modifiers such as .operation__send-address--invalid are used, but sometimes in combination with global selectors. This makes it harder to track what exactly is being modified.
   • Recommendation: Use modifiers strictly within the context of the block and avoid :global unless absolutely necessary.
   • Example:

     - :global(.dusk-textbox.operation__send-address--invalid) { ... }
     + .operation__send-address--invalid { ... }

     This keeps the modifier closely coupled to the element it is modifying.

4. Global Selectors and Nesting

   • Issue: There is an overuse of :global selectors (e.g. for .dusk-amount__icon) and deeply nested selectors which can break the encapsulation intended by BEM.
   • Recommendation: Where possible, move styles into the local scope of the component. Flatten nested selectors to lower specificity and to make the BEM structure more transparent.
   • Example:

     - :global(.dusk-amount__icon) { width: 1em; height: 1em; }
     + .operation__icon { width: 1em; height: 1em; }

Implementation Notes

• Shared Markup: Identify and isolate the common elements between Send and Stake. Refactor their markup to use the same BEM-based class names (e.g., .operation__address, .operation__input, .operation__review-label).
• CSS Refactoring: Adjust the Send component’s CSS to enforce BEM conventions strictly. Once the changes for Send are finalized, replicate the same changes for the Stake component.
• Testing: After refactoring, conduct visual regression and functional tests to ensure that the styling remains consistent and that no layout or behavior issues are introduced.

Next Steps

1. Review Proposed Conventions: Verify that the proposed block and element names meet our architectural goals for consistency between Send and Stake.
2. Refactor Send Component: Update the Send component’s markup and CSS according to the outlined recommendations.
3. Apply to Stake Component: Once the Send refactoring is validated, apply similar changes to the Stake component.
4. QA & Testing: Perform thorough testing to ensure that both components render correctly and that shared styles are applied uniformly.