Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type safety #28

Open
JUtupe opened this issue Dec 9, 2024 · 0 comments
Open

Type safety #28

JUtupe opened this issue Dec 9, 2024 · 0 comments

Comments

@JUtupe
Copy link

JUtupe commented Dec 9, 2024

Is your feature request related to a problem? Please describe.
When using Eventrix, we need to manually specify the return type of each useEventrixState hook. This can lead to potential type mismatches between the store and state types, especially when dealing with complex store structures.

Describe the solution you'd like
I propose that the types for useEventrixState be automatically inferred based on the Eventrix store type. This would simplify usage and reduce the potential for type errors.

For instance, consider the following example:

// store.ts

type Task = {
    id: number;
    title: string;
    status: string;
}

type Store = {
    tasks: Task[];
    test: {
        example: string
    }
};

const initialState = {
    tasks: [],
};

export default new Eventrix<Store>(initialState, taskEventsReceivers);
// TodoList.tsx

const TodoList: React.FC = () => {
    const [tasks] = useEventrixState<any[]>('tasks');

  ...
}

In this case, the type of the tasks variable should be automatically inferred as Task[].

Additionally, the type inference should also work for nested states. When using useEventrixState with a path like 'test.example', the type should be inferred as string.

Additional context

A similar feature exists in the React Hook Form library, where the types for form values and errors are automatically inferred based on the form schema.

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

No branches or pull requests

1 participant