use typed javascript in mathsteps about mathsteps HOT 19 OPEN

We should probably hold off until #144 lands. Sorry for dragging my feet with that. Definitely encourage experimentation though. :)

from mathsteps.

You might also want to consider Typescript here. I have used both and they each have pros and cons but it seems Typescript would be more appropriate for this project. It has better editor integration and it is much more widespread, making it easier for new contributors to get started.

from mathsteps.

I love types and flow is a great tool, so I think it's a good idea. Longer-term goal makes sense.

from mathsteps.

Relevant: https://dev-blog.apollodata.com/javascript-code-quality-with-free-tools-9a6d80e29f2d#.mfe1gsx20

from mathsteps.

The parser I'm working will have a different AST structure. As part of that work I'm adding a rule rewriting system. This will allows changes to be defined as strings of math with placeholders, e.g.

const rule = defineRule("#a + 0", "#a");
if (canApplyRule(rule, oldNode) {
    const newNode = applyRule(rule, oldNode);
}

You can follow that work at semantic-math/math-parser#27.

I think that having a system like this will simplify the existing search/transform functions substantially, but it will mean lots of changes to those files. If people are interested in adopting a system like this, then I think it's probably best to start using Flow/Typescript in files outside of search.

from mathsteps.

opinion from Kevin on gitter:

I think for library work, TS is the right call. I think the stricter nature of structural typing will catch more issues.

from mathsteps.

I'm cool with either.

from mathsteps.

edited the issue to reflect what we're talking about better

yeah @hmaurer that makes sense. I'm not super familiar with either, but if they both do a good job and typescript is more common that sounds like a good reason to use it :)

from mathsteps.

@evykassirer I think we can close this for now; it's probably not something that will be implemented in the near future (following month or so) and it might be clearer if open issues actually correlate to things being worked on. Maybe we could have a list on the wiki of "long term goals" and open issues for them once we actually start work on one of them?

from mathsteps.

I think it's worth keeping open and tagging with 'long term goals' as it is right now, so that there can be discussion on it (like what you posted yesterday!)

If people want to find things to work on, I hope they can filter out things with the long term label on them. Does that seem reasonable?

Thanks for looking through these and helping clean things up :) I'm also a fan of checking things off and having fewer things on my todo list and having things clean!

from mathsteps.

Should I try Flow ? and see how it goes ?

from mathsteps.

I think we were considering TypeScript instead. We should probably make an educated decision before going forward with one. If you can implement typed javascript in some files but not others, you could try it out for a file or two to see what it would look like :)

from mathsteps.

This may help https://github.com/Microsoft/TypeScript-Handbook

from mathsteps.

Hi all,
Since TS is a superset of JS, shouldn't migrating to TS simply integrating the TS compiler? According to this documentation page, all migration involves is literally just changing the file extension, since static types are actually optional.
EDIT: If it's ok with the other maintainers, I can try to send in a PR for the migration to TS within the next couple days; Resharper seems to have a really good tool to assist in the migration.

from mathsteps.

thanks to @elu00 for this great progress:

https://github.com/elu00/mathsteps-ts

from mathsteps.

What I gather through a little bit of research:

Background (hehe idk):

• Typescript: Microsoft, inspired by C# or Java type systems
• Flow: Facebook, written in OCaml

Porting:

• TS: Change extension for TS from .js to .ts
• Flow: add @flow annotation on top of the file that you want to be checked

What it does and general notes:

TS:

• includes a type checker AND has a transpiler that converts to native JS code
• uses something called declaration files (defines an interface to a library similar to what @elu000 found),
  these are very useful when interacting with third party libraries

Flow

• only does checking (comparable to a linter)

Notes:

• Structurally typed in TS (compared based on structure) vs nominally typed in Flow(..based on name) <- just putting it out there - I don’t think that necessarily affects anything

Both have this:

• Maybe types (e.g var num (value: ?number) … ) in this case number can be either number, null, or undefined
• Disjoint unions (e.g type Result = Done | Error) allows us to explicitly list out the possible shapes of results
• can be one or the other (this might be useful for our purposes, but not entirely sure right now)

Pro Flow:

• Flow is in ways less obtrusive, you can add in Flow code incrementally
• Strip down flow type annotations with Babel plugin

Against Flow:

• (http://jan.varwig.org/2017/02/15/flow-vs-typescript.html) <- This guy is strictly against Flow because it returns unhelpful error messages (doesn’t say where the error occurs so users have to guess) and has bad tooling (new contributors might need to use another supporting binary to test Flow -> Nuclide)

• In general, most of the online blog posts are very neutral and don’t have much of an opinion (typical)
• Syntactically there is not much of a difference. In summary, TS generally does more accurate testing,
• Flow has bad error messaging (EDIT: nitin claims that this isn't a problem).
• I am leaning a little bit more towards TS because of the added convenience when using libraries and it’s better documentation.

from mathsteps.

Bad error messaging is due to poorly configured .flowconfig. I've been through this. For example -

[ignore]
.*/node_modules/.*
.*/index.js

[include]
.*/node_modules/styled-components/.*
[libs]

[options]

In the above example I've included the dependency styled-components in the [include] section because I am also type checking the styled components in my library. So I need to tell Flow that include this dependency also (else it would give daunting errors). Here the author of styled-components has added support for the Flow but this is not the same for the other node modules. So yes I totally agree on the bad error messaging and also that mathjs don't have the support for Flow, so it may be beneficial if we use Typescript.

from mathsteps.

One more thing, as @kevinbarabash is working on the new parser, I was thinking that it may help (me or someone else) to include the support for Flow in mathsteps. So If a developer is using mathsteps directly or we expose the api for the new parser in future, we should definitely include support for both Flow and Typescript. ?

from mathsteps.

it seems like it would be a good idea to wait for Kevin to make more progress until we start implementing typed javascript (adding blocked to the tags) - though we can keep talking about it, and if someone thinks there'd be benefit in adding it now I'm definitely open to talk about it

there are some other issues open for bugs and functionality that seem like a better place to put focus on for now (and I'll be adding a bunch more in the next few days!)

from mathsteps.