-
Notifications
You must be signed in to change notification settings - Fork 91
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
Add some typescript type definitions #113
Conversation
* develop: (39 commits) Add samples to readme Bump version number Update both demos to BJS 4.0.3 Turn on the `debug` option in both demos Add license file and comment block Belatedly add `noa.version` string Add global `noa` reference in test apps Catch meshing error that can trigger if client code twiddles certain voxel data between chunk creation and first mesh Increment webpack-dev-server to fix warning message Typos Generate a package-lock.json and unignore it Support development on Windows machines Expose `noa._constants`, and make `noa.addBlock` return the assigned ID Tweaks - remove some unused code, fix a few misc types Update dependency Update ECS dependency for bugfix Debounce how often babylon engine `resize` gets called Add update log for v0.25.0, and note about working in develop branch Fix outdated stuff in readme Remove `markdox` dependency, and doc generation script (that wasn't being used) Rebuild demos in newest webpack Updating dependencies, webpack3 -> webpack4 ...
* develop: Rebuild demos Log version, and add `silent` option
Bumps [eslint-utils](https://github.com/mysticatea/eslint-utils) from 1.3.1 to 1.4.3. - [Release notes](https://github.com/mysticatea/eslint-utils/releases) - [Commits](mysticatea/eslint-utils@v1.3.1...v1.4.3) Signed-off-by: dependabot[bot] <support@github.com>
…slint-utils-1.4.3 Bump eslint-utils from 1.3.1 to 1.4.3
Hi, this looks really useful! Way back in the day I used to get full autocomplete suggestions like this from VSCode even without typings, but it stopped working at some point and would be great to get back. Let me take this for a spin in my own env and check that I get the same results. BTW: I generally keep all new dev in the #develop branch, so I'll edit this PR to base against that. Never tried changing the base of a PR before; hopefully it won't mess things up. |
I think VSCode’s automatic autocomplete stuff works a little better with
ES6 classes than Classname.prototype.methodName style - not sure why though.
I based it on master because there are no functional code changes but I can
see why develop makes more sense
Feel free to edit as you see fit, though I’d feel bad if this just creates
work for you
For types to be really nice, would also need to do it for ECS and the
physics engine — but it would get pretty tricky with custom components.
There’s probablyyy a way to do that in TypeScript but often being fancy
with TypeScript or Flow ends up causing issues later. I personally only
care about nice autocomplete and figured some types was better than not
having them
As a side note, I briefly explored moving the terrain mesher stuff to a
worker but it’s really complicated to do that. The best approach I can
think of involves SharedArrayBuffer but Firefox / Safari wont like that. I
might explore doing that later
…On Thu, May 28, 2020 at 9:42 PM Andy Hall ***@***.***> wrote:
Hi, this looks really useful! Way back in the day I used to get full
autocomplete suggestions like this from VSCode even without typings, but it
stopped working at some point and would be great to get back. Let me take
this for a spin in my own env and check that I get the same results.
BTW: I generally keep all new dev in the #develop branch, so I'll edit
this PR to base against that. Never tried changing the base of a PR before;
hopefully it won't mess things up.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#113 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFNGS2SMMPW6UK7OMAMNJ3RT44MJANCNFSM4NJDWNWA>
.
|
Yeah, we're in agreement. Getting good code hints is definitely worth adding a build step, but while somebody could certainly add manual annotations to say that e.g. As for the mesher, yeah it should be possible in principle, but it's hairy (since there are already a lot of async steps in that process), and it's not obvious that it would wind up being a performance win. (Assuming the perf issue you were seeing with array merges is fixed, I mean.) So for those reasons I've been figuring it's best for meshing to stay synchronous for now. |
Sorry for the delay on this, for some reason I can't seem to get the nice code hints to show up in my local environment but I'll go ahead and merge this on the assumption that it's working somewhere, maybe it can be fixed later. |
The majority of this was auto-generated by running the following command:
Then I went through and converted some of the
any
to a more specific type.These are not exhaustive types, but it makes VSCode autocomplete much better.
Examples:
Before this, it wouldn't show me inline autocomplete for anything in noa and I had to check the API.md docs a lot
Might be nice to remove all the definitions for
noa
in the classes and then anything prefixed with an_
. I sometimes use the_
functions though.