Skip to content

feat: improve TS typing and refactor examples#18

Open
lucataglia wants to merge 3 commits intomainfrom
feat/improve-ts
Open

feat: improve TS typing and refactor examples#18
lucataglia wants to merge 3 commits intomainfrom
feat/improve-ts

Conversation

@lucataglia
Copy link
Collaborator

No description provided.

@lucataglia lucataglia requested a review from rivamarco February 19, 2026 09:31
@TheFe91
Copy link

TheFe91 commented Feb 19, 2026

  1. SuccessSubmitCallback vs SubmitSuccessCallback — inconsistent naming

// src/types/index.ts
export type SubmitSuccessCallback = ...
/** @deprecated Use {@link SubmitSuccessCallback} instead. */
export type SuccessSubmitCallback = SubmitSuccessCallback

The [Verb][Noun]Callback pattern (e.g. CheckSuccessCallback, CheckErrorCallback) is used for check callbacks, but submit uses SubmitSuccessCallback. This is fine, but worth noting as an
explicit naming decision.

  1. PrivateValidateForm moved without apparent breaking change, but with semantic shift

// Previously in the public section, now @internal
export type PrivateValidateForm = (...)

It was already @Private in JSDoc, but it's still exported. If someone imports it directly (unlikely but possible), there's no deprecation warning. Consider whether to add @deprecated or
leave it as is.

  1. liveValidation — ambiguous name in FormbitObject

liveValidation: (path: string) => true | undefined,

The liveValidation field in the return object was previously of type LiveValidationFn (a function), and LiveValidation in the state was the record. Now both are named liveValidation
(one is the function, the other is the field in the writer), but in FormState the field is typed as liveValidation: LiveValidation (the Record). This can create confusion: a consumer
reading formbit.liveValidation expects a function, but writer.liveValidation is a record. Not a bug, but an asymmetry worth documenting.

  1. FormbitObject — check at the bottom

return {
// ...
submitForm,
check // ← last
}

In the return object ordering, mutations follow a logical sequence (write → remove → initialize → reset → set → validate → submit → check), but check is semantically different from
submitForm — it doesn't mutate state, it doesn't submit, it's closer to a query. It could belong in the // Queries section.

  1. FormbitValues and Form / InitialValues are now aliases of the same type — this clarifies that Form and InitialValues are interchangeable, but it might be worth documenting
    explicitly.

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.

2 participants

Comments