Comments (10)
The node16
resolution type is the correct one for native ESM, and therefor for unified packages internally. Unfortunately not all of the ecosystem is compatible yet (davidbonnet/astring#646). This needs to be resolved first, then I can look at how all of this affects hastscript
.
A quick history on this topic:
- At first the TypeScript JSX namespace had to be global.
During this time the React types were created.
declare global { namespace JSX { // … } }
- At some point TypeScript allowed specifying local JSX namespaces
This allows people to mix multiple JSX implementations in different filed within the same project 🤯 So these two files could live in the same project:
declare function h(); namespace h.JSX { // … }
// react-hello.tsx// hastscript-hello.tsximport React from 'react' const Hello = () => <div>Hello</div>
/* @jsx h */ import { h } from 'hastscript' const Hello = () => <div>Hello</div>
- Then the automatic runtime was released.
As far as I know, this requires a global JSX namespace. However, this issue suggests this is incorrect. If this is indeed incorrect, then IMO it is the desired behaviour, because it would allow to mix multiple JSX implementationg using JSX comments.
I do think it would be nice to expose the HResult
type though. I totally agree it makes sense to use this type, i.e. for explicit return types as the OP suggests.
import { HResult } from 'hastscript'
const Foo = (): HResult => <div />;
from hastscript.
it would be bad to do this?
Yep! Looks like JSX
isn't meant to be accessed ever.
exposing
HResult
is an adequate solution?
I believe so. The name is a little cryptic, but it's not worth a refactor, and breaking existing consumers.
from hastscript.
Sounds like something @remcohaszing has ideas on!
from hastscript.
Thanks, that makes sense! So I went ahead and checked if anybody has reported this in TypeScript, since this feels like their responsibility, and I found something even better: microsoft/TypeScript#41330 (comment) Here's how Preact implemented it: https://github.com/preactjs/preact/pull/2811/files Edit: And I see that it's already exported, so why doesn't it work? Edit 2: Ah, likely because it isn't re-exported here and here and here. Edit 3: No, I still don't understand why this isn't sufficient:
// svg/jsx-runtime.d.ts
export * from '../lib/runtime-svg.js'
// lib/runtime-svg.d.ts
export * from './jsx-automatic.js'
// lib/jsx-automatic.d.ts
export namespace JSX ...
Edit 4: Okay, finally found the definitive answer to this: microsoft/TypeScript#47072 (comment) The JSX namespace is an implementation detail, not meant to be public. So, in the end, import { HResult }
is the way to go.
from hastscript.
As far as I understand the above comments, then it would be bad to do this?
And exposing HResult
is an adequate solution?
from hastscript.
I’m up for exposing HResult
, I don’t see downsides.
@alecmev Interested in working on a PR?
from hastscript.
Hi! This was marked as ready to be worked on! Note that while this is ready to be worked on, nothing is said about priority: it may take a while for this to be solved.
Is this something you can and want to work on?
Team: please use the area/*
(to describe the scope of the change), platform/*
(if this is related to a specific one), and semver/*
and type/*
labels to annotate this. If this is first-timers friendly, add good first issue
and if this could use help, add help wanted
.
from hastscript.
Hi! This was closed. Team: If this was fixed, please add phase/solved
. Otherwise, please add one of the no/*
labels.
from hastscript.
Released in 7.1.0!
I noticed that HChild, HProperties, were also exposed as Child
and Properties
, so I used Result
as the type name for this
from hastscript.
Sorry for the radio silence, thank you!
from hastscript.
Related Issues (13)
- Add support for normalising tag names HOT 1
- Add type definitions
- Dynamic import issue for TypeScript 4.5.0-beta "module" of "nodenext" or "node12" HOT 8
- Allow functional components in JSX HOT 27
- custom element attributes are returned as children rather than properties HOT 35
- Support for Exotics HOT 15
- Issues bundling for production with `camelcase` dep HOT 3
- SVG support HOT 1
- How to create boolean attributes? HOT 7
- Support camelCased source properties HOT 15
- Strict comparison between self cannot occur HOT 3
- Add docs for different `h()` algorithms HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hastscript.