Typescript definitions

[r0skar]

Hi! Thanks for sharing your work with us! I was wondering if you have any plans to provide typescript definitions? I started to really like typescript, but I am not yet capable of writing definitions for a complex framework like yours.

[ryansolid]

I've been waiting for this issue to show up.

I've known there would be a desire and I've actually attempted to rewrite my libraries in TypeScript on a couple occasions, because I believe for a library having that API surface covered is invaluable. For some reason I've really struggled with this though(unlike Flow) and admittedly I haven't invested enough time. But I also haven't not invested a good chunk of time.

I'd love to help out here but it might be a slow go. But now that there is a standing issue I will probably get to this again sooner than later, or at least put it out there to get some assistance. I think it is pretty likely I will move the whole set of libraries to TypeScript at some point if I can ever get past the continually horrendous experiences I have every time I give it a chance.

[r0skar]

I believe for a library having that API surface covered is invaluable.

That's so very true. It is so much easier to get into a new library when the Editor/IntelliSense is doing all of the guess work about available methods and exports.

I think it is pretty likely I will move the whole set of libraries to TypeScript at some point if I can ever get past the continually horrendous experiences I have every time I give it a chance.

IMO, the great thing about Typescript is, that basically any JS code is valid TS code as soon as you change the file extension to .ts. I have tried to port this repo to TS and it works without any modifications: https://github.com/r0skar/solid. The few reported type errors are minor. I´d be happy to keep hacking at this.

Since the S library is using Typescript, IntelliSense did already pick up a few warnings (Should this be a new Issue?):

// src/state.ts (Line 46 & 50)
// S.js requires an argument for makeDataNode()
node = nodes._self || (nodes._self = S.makeDataNode());

// src/dom/index.ts (Line 18 & 36)
// S.js requires a seed value as second parameter when the first param is a fn that takes an argument.
S.makeComputationNode(element => {})

[ryansolid]

Ok yeah I hit those warnings too. It's because I don't explicitly pass undefined in both scenarios. They are fairly trivial to address. But I see you have no type annotations yet. I was using strict: true. It's also possible to start loose and then make it more strict over time but I don't really see the benefit of TypeScript in that case. So I was getting annoyed pretty quick having to cast Node to HTMLElement back and forth for like nextSibling calls and in the end still having it complain.

I figure the easiest way to attack this systematically is start with the libraries with no deps and work up. S.js being TypeScript helps but I think the logical order is dom-expressions > lit-dom-expressions & hyper-dom-expressions > Solid. The fact I broke out from the Babel Plugin is nice since I was having a hell of a time since I couldn't seem to get types for Babel to work. Now it isn't really needed.

[neodon]

I came across Solid today and I'm loving it so far. After dealing with beastly frameworks for the last few years, I'm ready to pare it back and recover some performance / mindspace.

I noticed pretty quickly that there aren't TypeScript definitions. I've been deep down this rabbit hole lately, particularly using Babel's new preset that just strips the TypeScript out to transpile it. This just leaves the typescript compiler creating the declaration files.

I'm willing to spend some time towards helping get a TypeScript foundation in place for this project, but I do have a question about build tools. I don't have any problem with Rollup, I'm just not familiar with it--it's on my list of cool things to learn. Are you set on keeping Rollup, or would you be OK with a webpack setup as long as it's not a nightmare to deal with?

[ryansolid]

Rollup produces smaller bundles. It makes a difference when I'm trying to win at benchmarks. I've used Webpack for years and still do for apps but for libraries like this Rollup is a better choice. Babel is trivial with Rollup(https://github.com/rollup/rollup-plugin-babel), although I haven't used any of the TypeScript plugins.

Although that piece isn't the hard part for me. I can do build tool configurations all day. I just haven't figured out how get the types to work. So realistically I can take whatever and make it work.

[neodon]

Cool, thanks for the quick response. I think I'll take this opportunity to give Rollup a try then.

[neodon]

I made a bit of progress in my branch (neodon/solid/typescript). It transpiles the top-level modules from TypeScript to JavaScript when bundling, and emits type declarations that are usable in VSCode in my sample Solid project.

I only made the minimal changes needed to get a successful build with the TypeScript compiler, so there will be more work to do there. I'm going for incremental improvements.

I kept a close eye on the bundle sizes since you mentioned that as a concern. The file sizes did increase with Babel, but I think it's almost all whitespace changes. I just learned that Babel has support for some basic minification that could further reduce sizes, which is cool. Let me know if you want me to work on minification or at least reducing the extra whitespace.

You'll notice a bunch of files related to my VSCode workflow, including configs for eslint, prettier, and a VSCode workspace. I intend to exclude that commit from pull requests, unless you are interested in adopting any of it in the project. I tried to remove some of the more opinionated settings and make things optional.

I'd appreciate any feedback you have before I continue.

[ryansolid]

Ok , this all looks pretty good. Don't worry about the minification piece as of yet. I am not minifying the dist currently allowing that responsibility to land on the final application. It is more about just avoiding extra code generation. The small changes I will just review and tweak after the pull request. I will likely just run this through my gauntlet of benchmarks to see impact. The forcing of passing values to some of S methods is a tiny bit awkward but I think explicit undefined or null should do the trick.

As for the project settings. I think leave them out for now. I don't mind the .vscode settings, but I haven't really figured out a preference on the other stuff. Just bare with me a bit, as this sort of tooling I'm more unaccustomed to as I was long time on CoffeeScript and stuff like this simply didn't exist for it. I think it is probably grand time to update the processes for this stuff but I think a piece at a time as I've found taking on too much at once tends to get in the way more at first.

In any case I appreciate you looking into this. And I will in the meanwhile catch up on my TypeScript knowledge. It might start with Solid, but it is really just an implementation on top of bunch of libraries that I've been building to support Fine Grained UI Rendering. I will setup the same base with DOM Expressions and work out from there. I was originally going to do CLI tools next but I think if I need to work on the development experience of these projects before I can really strongly give an opinion on the best experience for those that use Solid.

[neodon]

Thanks for the feedback. Here is what I gathered from your response:

• I won't worry about minification or whitespace.
• I see how the forced argument to the S methods could be clunky. I think I can tweak the TypeScript code to not require a parameter for those S methods (so implicit undefined) to preserve the original behavior. I haven't dove in to the underlying code that makes SolidJS possible, but I'm interested in learning more.
• I'll leave out my project settings from any pull requests. I definitely agree with your approach of introducing one thing at a time.

A couple extra notes:

• Since the Babel transform just strips out the TypeScript, I wanted to note that emitting the type declarations during the build ensures the TypeScript is valid (based on how strict the tsconfig.json settings are). That reduces the dependence on an IDE workflow for type-checking and linting.
• If you are interested in trying out the workflow I have set up sometime, open the solid.code-workspace file in VSCode, then go to Extensions and put @recommended in the search. Once you install the workspace recommendations, you can restart or reload VSCode and it should all come to life. There are a lot of warnings right now that I'm ignoring, but I think it would be best to start over with a minimal ruleset and build on it thoughtfully. If/when you want to do that, of course.

Did you want me to continue with some more incremental TypeScript additions as I have time?

If so, would you like me to send occasional pull requests for a parallel typescript branch in this repo? That way you can make tweaks and manage what pieces eventually get merged into master, if any. I'm open to any changes, deletions, or criticisms for code I've written.

I don't have much experience contributing to public projects, so you'll have to bear with me.

[ryansolid]

Yeah sounds good as I am unsure how quick my progress will be on this. As I'm likely to attack other repos before Solid as I'm learning. And I'd like to introduce it as it makes sense to. I have made a typescript branch and you can do pull requests against. Let's get your initial pull request in there, and we'll see how it goes from there.

[ryansolid]

I've completed the initial migration to TypeScript migration. @r0skar and @neodon thank you both. These are far from perfect and I will accept PRs which can improve them but this at least serves as a baseline.

The last missing piece is JSX and Template/Component defs but I believe those belong with the Babel plugin. I've created an issue https://github.com/ryansolid/babel-plugin-jsx-dom-expressions/issues/7 to track this effort.