@base316/react 0.6.0 → 0.8.0

package/CHANGELOG.md

@@ -1,5 +1,74 @@
 # @base316/react
 
+## 0.8.0 — 2026-11-06
+
+Published after `@base316/sdk` 0.10.0 (the workspace dependency pins it), so
+release the SDK first.
+
+### Added
+
+- `useAddons()`: the signed-in user's addons (`attached`, `available`) with
+  `attach`, `setQuantity` and `remove`, over the SDK's self-serve addon
+  methods. No markup, like `usePlans`; `lastError` is the API's code
+  (`no_payment_method`, `already_attached`, …).
+
+- `SignUp` shows the environment's Cloudflare Turnstile check when the sign-up
+  CAPTCHA is on, and sends its token with the form. **Upgrade before setting the
+  CAPTCHA to refuse:** `SignUp` from 0.7.0 and earlier sends no token, so every
+  sign-up through it is refused (`CAPTCHA_FAILED`), or recorded as a failure in
+  record-only mode. If your site sets a Content-Security-Policy, allow
+  `https://challenges.cloudflare.com` for scripts and frames.
+
+### Fixed
+
+- `SignUp` with passwords off and no social provider showed a password form
+  the API refuses (`403 METHOD_DISABLED`); it now says creating an account is
+  not available (`labels.noMethods`). With a provider, it shows the provider
+  buttons alone, as before.
+
+### Changed
+
+- US English throughout: component text, default labels, the component
+  manifest's descriptions and the type documentation now read "color",
+  "canceled", "enrollment", "behavior" and so on. Class names (such as
+  `b316-mfa-enrol`), element ids, props and label keys are unchanged.
+
+## 0.7.0 — 2026-10-29
+
+Needs `@base316/sdk` 0.9.0 (`auth.methods`, `socialSignInUrl`), so release the SDK first.
+
+### Changed
+
+- **`<SignIn>` and `<SignUp>` follow the environment's sign-in settings.** They
+  read `GET /v1/auth/methods` and offer what the dashboard has switched on —
+  password, magic link, passkeys, text-message codes, social providers and SSO —
+  instead of what props turned on. Props can now only turn a method **off**
+  (`password`, `passkeys`, `magicLink`, `phone`, `social`, `sso` = `false`).
+  Two consequences to check when upgrading: passkeys appear only where the
+  environment allows them (they were on by default), and `phone` no longer turns
+  text messages on by itself. Until the answer arrives, or against an older API,
+  the form draws as before from its props.
+- A magic link lands on the page rendering the form unless
+  `magicLinkRedirectUrl` says otherwise (it must be on the redirect allow-list).
+
+### Added
+
+- Social sign-in buttons — "Continue with Google", "Continue with Apple" and the
+  rest — with each provider's mark and colours, on `<SignIn>` and `<SignUp>`,
+  when `socialRedirectUrl` names your server route that receives the `code`.
+  The button writes a `b316_oauth_state` cookie and sends the same value as
+  `state`; check them with `readOAuthState` before `exchangeCode`.
+  `socialState` carries a value of yours through.
+- `<SocialSignIn socialRedirectUrl>`: the same buttons alone, for a sign-in or
+  sign-up form an application draws itself (`intent="sign-up"` hides them when
+  the environment is closed to new accounts; `divider` draws the "or" rule).
+- "Sign in with SSO" on `<SignIn>` when an enterprise connection claims a
+  domain: the person types their work address and goes to their identity
+  provider.
+- `labels` on `<SignIn>` (`SignInLabels`) for every string it shows, and new
+  `continueWith`, `or` and `closed` on `<SignUp>`. A closed sign-up says so
+  instead of offering a form, unless the page carries an invitation.
+
 ## 0.6.0 — Unreleased
 
 Needs `@base316/sdk` 0.8.0 (`Base316Browser` `organizationId`), so release the SDK first.

package/README.md

@@ -24,7 +24,7 @@ export default function App({ children }) {
 
 The provider holds one client and the signed-in user's session, and fetches the
 branding you configured in the Base316 dashboard — so what you set there is what
-these components look like here. No colours to keep in step in two places.
+these components look like here. No colors to keep in step in two places.
 
 ## Sign in, in your own page
 
@@ -59,7 +59,7 @@ import {
 
 Three ways, from least to most invasive. Use the first that works.
 
-**1. The dashboard.** Whatever you set under _Sign-in pages_ — brand colour,
+**1. The dashboard.** Whatever you set under _Sign-in pages_ — brand color,
 background, logo — arrives here automatically.
 
 **2. `appearance` tokens.** No CSS to write:
@@ -74,7 +74,7 @@ background, logo — arrives here automatically.
 **3. Your own CSS**, targeting the `b316-*` class names, or a `className` on any
 component to hand it your utility classes.
 
-Every colour, radius and font is behind a `--b316-*` custom property. Nothing
+Every color, radius and font is behind a `--b316-*` custom property. Nothing
 inherits your application's styles automatically — silently absorbing whatever
 `body { font }` and `button { }` rules happen to exist produces components that
 look broken in ways neither side can predict.