Open 38elements opened 4 years ago
The typings for compat were initially created for those wanting to use pieces from compat
while in a preact only space (ie Suspense/Portal etc).
I think preact/compat
is compatibility layer.
I think the initally papose of typings for preact/compat
is different from preact/compat
.
I think it needs compatibility, since it is the typings for compatibility layer.
What changes would you propose? For those who directly import preact/compat
in a TS project (without React) these typings are required.
Yes the main purpose of compat
is for React compatibility, but it can also be used directly. If you are using React with a build system that aliases to preact/compat
, the React typings should (and I believe are) used instead of the typings in preact/compat
.
I am not familiar with preact/compat
.
I may be misunderstanding.
I t seems that preact.VNode
is incompatible with React one.
@38elements you're not expected to use the typings from both libraries
Ideally you'd want to alias it both for webpack and typescript
In the case using React library whose code creates VNode in TypeScript, I think it may raise error. This may be rare case.
I recall testing having a mixed system of preact/React in Typescript and it worked as expected. Webpack did the aliasing to compat
, but VSCode was showing React typings on React components and preact typings on preact ones with no problems (this was a little while ago but nothing fundamental has changed)
I think most React library does not have code which creates VNode (createElement()
by one's own work), since they uses createElement()
in React.
May I confirm?
In compat
, Does it not raise the error like #1953?
IMHO,
compat
exists for compatibility for React. Therefore, the type definition which is provided bycompat
should be compatibility for React.compat/src/index.d.ts
should give priority to compatibility over precise.src/internal.d.ts
exists for Preact.src/internal.d.ts
should give priority to precise over compatibility.