Skip to content

Merge develop into main - #90

Merged
Arthurk12 merged 13 commits into
mainfrom
develop
Sep 30, 2026
Merged

Arthurk12 merged 13 commits into
mainfrom
develop

Conversation

@Arthurk12

Copy link
Copy Markdown
Member

Merge develop into main

  • BBBSlider: add slider component
  • BBBAvatar: add avatar component
  • BBBCheckbox: add dataTest prop for the underlying input and respect the caller-provided id
  • BBBModal: add hideCloseButton prop to hide the header close button and remove an unused styled-component
  • BBButton: make size also resize the circle and squared layouts

Arthurk12 and others added 13 commits September 1, 2026 13:28
chore: sync v0.7.0 from main into develop
`circle` hardcoded a 3rem width/height regardless of `size`, and
`squared` hardcoded its padding, overriding the size-derived padding
from commonButtonStyles — both contradicted the `size` doc, which
claims it affects padding and the circle's diameter.

Add a shared `iconBoxSize` per size to CSS_SIZE_PROPERTIES and an
`iconOnlyBoxStyles` fragment reused by both layouts, so `circle` and
`squared` always render at the same fixed box size for a given `size`
(sm: 2rem, md: 3rem, the latter promoted to a new `spacingXXLarge`
token to match the previous circle default). This changes squared's
default look: it no longer sizes itself from icon + padding, and now
matches circle's box size instead.
BBBModal always renders a close button in the header, with no way to
suppress it. This blocks use cases that require a non-dismissible
modal, such as mandatory-action dialogs or modals whose closing is
controlled entirely by external logic.

Add a hideCloseButton prop (default false) that conditionally renders
the close button, following the same pattern already used by
noFooter.
styles.ts defines a CloseButton styled-component that is never
referenced: the modal's close button has always been rendered via
BBButton in component.tsx instead. Remove the dead code.
BBBCheckbox always rendered with an internally generated id from
useId(), because {...props} was spread before the explicit id
attribute, so the generated value silently overwrote any id passed
by the caller. This made it impossible to target the rendered input
by a known id and broke the label/htmlFor association whenever a
custom id was expected.

Destructure id from props and fall back to useId() only when the
caller does not provide one, reusing the resolved value for both the
checkbox input and the label's htmlFor attribute.
BBBCheckbox has no way to tag its rendered <input> for test
selectors. Spreading an arbitrary data-test through {...props} does
not work: MUI's SwitchBase only forwards explicitly recognized props
(id, checked, name, inputProps) to the actual <input>, so anything
else spread through falls into the outer wrapper <span> instead —
the same class of issue fixed for id in the previous commit.

Add an explicit dataTest prop, matching the convention already used
by BBButton and BBBInput, and route it through MUI's inputProps so
it lands on the real <input>, merging with any inputProps the caller
already passes directly.
The library has no reusable component for rendering a user avatar.
Every BBB surface that needs one — e.g. bbb-plugin-pick-random-user's
user-avatar — reimplements the same image/initials/color logic
locally, causing duplicated code and visual inconsistency across
plugins and apps.

Add BBBAvatar (src/components/Avatar), using bbb-plugin-pick-random-user's
user-avatar as the reference implementation, extended to mirror BBB's
own conventions rather than inventing new ones:

- Renders the avatar image, falling back to initials on a colored
  background when no image is given or it fails to load.
- The fallback color is hashed deterministically from the user's name
  into the same 16-color palette akka-bbb-apps' ColorPicker assigns
  server-side, so the fallback lands on colors real BBB users get.
- small/medium/large size variants (medium default).
- isModerator renders the rounded-square shape BBB uses for
  moderators, independent of color.
- isYou applies BBB's own "you" color (colorUserYou, added to the
  shared palette) in place of the fallback, overridden by an explicit
  color prop.
- isTalking shows a pulsing ring in the avatar's own color, mirroring
  BBB's talking indicator (ported to use CSS's native color-to-transparent
  interpolation instead of manual alpha-string concatenation, so it
  works with both hex colors and CSS custom properties).
- A Tippy tooltip shows the full name on hover; disableTooltip opts out.
fix(BBButton): make `size` resize `circle` and `squared` layouts
feat(BBBModal): add `hideCloseButton` prop to hide header close button
fix(BBBCheckbox): respect caller-provided id prop & feat(BBBCheckbox): add `dataTest` prop for the underlying input
feat(BBBAvatar): add avatar component
The library has no slider, so every range control in BigBlueButton
ships its own: the camera modal drives brightness with a raw
`input[type=range]` plus hand-positioned markers, while the profile
panel uses a bare MUI `Slider` with local `styled()` overrides. The
two disagree on range, on styling and on how the value is announced.

Add `BBBSlider`, a horizontal single-thumb wrapper around MUI's
`Slider`, so those call sites collapse onto one control. Its
appearance matches what the profile panel renders today — MUI's
defaults carrying the brand colour — so adopting it changes no pixels
there.

Three things are handled by the wrapper rather than left to callers,
because MUI gets them wrong by default in this context:

- `id` and `aria-describedby` are routed into the hidden range input
  through `slotProps.input`. MUI puts unrecognized props on the root
  `<span>`, which makes `<label htmlFor>` associate with nothing and
  silently strands the description on a non-focusable element.
- Right-to-left takes three separate repairs. The ambient direction is
  read from the DOM and re-provided to MUI through `ThemeProvider`,
  since `useRtl()` defaults to false and the client sets no theme
  direction. That switches MUI to right-anchored positioning but not
  the transforms paired with it, which normally come from an emotion
  cache running `stylis-plugin-rtl`, so the thumb and the marks are
  mirrored here instead — without it every one of them sits a full
  element width off and the thumb detaches from the track. The numeric
  labels also carry `unicode-bidi: plaintext`, without which a leading
  minus is reordered and `-100` paints as `100-`. `ThemeProvider`
  comes from `@mui/material/styles`, not `@mui/system`, so the context
  is the same module instance that renders the slider.
- The public props narrow MUI's `number | number[]` value and handlers
  down to `number`, and drop `orientation`, so the single-thumb
  horizontal scope is enforced by the types.

Two props cover what the call sites need beyond MUI's own API:
`showMarkTicks` keeps mark labels while hiding their tick dots, which
is what the camera modal's -100/0/100 scale needs, and `animate`
turns off every transition and hover effect. The keyboard focus ring
survives `animate={false}`, since removing it would leave the control
with no visible focus state.

The README covers the two usage patterns the component was designed
for — a value the user reads (volume) and one they only feel
(brightness) — along with the rules that are easy to get wrong.
feat(BBBSlider): add slider component
@Arthurk12
Arthurk12 merged commit 00708d5 into main Sep 30, 2026
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.

1 participant