Skip to content
This repository has been archived by the owner on Nov 9, 2024. It is now read-only.

types: refactor interfaces #632

Merged
merged 5 commits into from
Nov 2, 2019
Merged

types: refactor interfaces #632

merged 5 commits into from
Nov 2, 2019

Conversation

atomiks
Copy link
Owner

@atomiks atomiks commented Nov 1, 2019

  • Removes [key: string]: any from Props (see Typing problem with new native props + plugins #631)
  • Makes all interfaces that use Props become generic (to use TProps)
  • Add included plugins to Props so typechecking is enabled by default even if the plugin isn't passed (there is a DEV warning for this)

@atomiks atomiks requested a review from KubaJastrz November 1, 2019 05:50
@atomiks
Copy link
Owner Author

atomiks commented Nov 1, 2019

Also added: function overloading types so TS knows the return value based on the targets argument:

tippy('button') // Instance[];
tippy(document.body) // Instance;

delegate('button', {target: 'string'}) // Instance[];
delegate(document.body, {target: 'string'}) // Instance;

@atomiks
Copy link
Owner Author

atomiks commented Nov 1, 2019

I think we should just add all the plugin types to Props itself 🤷‍♂

For custom plugins, the user does something like:

src/tippy.ts

import tippy, {Tippy, Props, Plugin} from 'tippy.js';

interface ExtendedProps extends Props {
  customX: boolean;
  customY: number;
}

export const customX: Plugin<ExtendedProps> = {
  name: 'customX',
  defaultValue: false,
  fn: () => ({}),
};

export const customY: Plugin<ExtendedProps> = {
  name: 'customY',
  defaultValue: 0,
  fn: () => ({}),
};

export default tippy as Tippy<ExtendedProps>;

src/index.ts

import tippy from './tippy';

// Both overloading and typechecking for custom plugins work
// DEV warning that `customX` and `customY` plugins were not passed
const [i] = tippy('button', {
  customX: true, 
  customY: 1000
});

i.setProps({customX: false});

// Also included plugins become part of `Props` itself
i.setProps({followCursor: true}); // DEV warning that they didn't pass the plugin

This is the simplest usage I think.


That said it doesn't solve #631. There will be a type error if their plugin name conflicts with a newly introduced native one. There will be a DEV warning if this happens so they'll need to update the name to something else (or remove it). I expect this to be rare enough to not really be an issue, anyway.


I also noticed that adding the overload doesn't isolate the red squiggly type error line to a single prop, the whole thing becomes squiggly making it harder to track down the violating prop. I'm not sure if that's just the way TS is though.

@atomiks atomiks changed the title types: refactor interfaces to generics types: refactor interfaces Nov 1, 2019
@atomiks atomiks force-pushed the types/generic-interfaces branch 2 times, most recently from 0afe3df to 4b755ff Compare November 2, 2019 03:46
@atomiks atomiks force-pushed the types/generic-interfaces branch from 4b755ff to 5fe9918 Compare November 2, 2019 03:49
@atomiks atomiks merged commit dc672f4 into master Nov 2, 2019
@atomiks atomiks deleted the types/generic-interfaces branch November 2, 2019 03:52
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant