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

[TypeScript] More specific core-data selector types #41594

Closed
wants to merge 7 commits into from

Conversation

adamziel
Copy link
Contributor

@adamziel adamziel commented Jun 8, 2022

What?

This PR narrows down core-data selectors type signatures after somewhat general ones were introduced as a first step in #41235.

Why?

We want to have autocompletion and TypeScript support for core-data primitives as well as compile-time checks, see #39025 for more context.

Testing Instructions

  • Confirm the CI checks are green
  • Confirm the few runtime changes this PR introduces to make TS happy are sound

@noisysocks @sirreal @dmsnell @sarayourfriend

@adamziel adamziel added [Package] Core data /packages/core-data Developer Experience Ideas about improving block and theme developer experience labels Jun 8, 2022
@adamziel adamziel self-assigned this Jun 8, 2022
@adamziel adamziel changed the title Increase specificity of core-data selectors signatures [TypeScript] More specific core-data selector types Jun 8, 2022
Base automatically changed from ts/add-tsconfig-json-to-core-data to trunk June 10, 2022 09:51
@adamziel adamziel force-pushed the ts/add-missing-core-data-selectors-signatures branch from 540fe09 to 5e389ac Compare June 10, 2022 09:52
@fabiankaegy fabiankaegy removed their request for review June 10, 2022 10:01
- _name_ `Name`: Entity name.
- _recordId_ `GenericRecordKey`: Record's id.
- _kind_ `K`: Entity kind.
- _name_ `N`: Entity name.
Copy link
Member

@dmsnell dmsnell Jun 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when I mentioned having a different name for the public vs. the internal use of function arguments this is one of the reasons why. we like to have short names internally but K and N are vague to the outside.

we can solve this in the source files by importing * as …

import { …normalImports } from './entity-types';
import type * as ET from './entity.types';

export const doer<Kind extends ET.Kind, Name extends ET.Name>() => 

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! I just updated this PR @dmsnell

@@ -192,11 +192,11 @@ Returns the loaded entities for the given kind.
_Parameters_

- _state_ `State`: Data state.
- _kind_ `Kind`: Entity kind.
- _kind_ `ET.Kind`: Entity kind.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not ideal that the docs mention both ET.Kind and Kind, but tradeoffs, tradeoffs 🤷

@@ -174,11 +174,16 @@ const reduxStore = createStore();

const boundSelectors = mapValues(
existingSelectors,
( selector ) => ( ...args ) => selector( reduxStore.getState(), ...args )
( selector ) =>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ESLint likes to format code in a different way now and it picked up README.md for some reason

@adamziel
Copy link
Contributor Author

Closing in favor of #42238

@adamziel adamziel closed this Jul 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Developer Experience Ideas about improving block and theme developer experience [Package] Core data /packages/core-data
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants