Giter Club home page Giter Club logo

Comments (3)

vivian-farrell avatar vivian-farrell commented on June 7, 2024

Personally I'm not a fan of typescript mainly because I think the extra code and overhead outweighs the benefits. It's not used much in the react community but is required for angular 2. Not sure if there would be much benefit for this library unless typescript was also used on the consuming end as well. Maybe exposing the ts files would be a nice extra but unless people really need it, it could just be more overhead.

from redux-subspace.

mpeyper avatar mpeyper commented on June 7, 2024

That's interesting to me because I would say that the extra code (of both Typescript and Flow - there isn't much difference in my opinion) add a huge amount of benefit to me in the form of confidence that the code does what I think it does. I would even say that if you are using ES6, the amount of extra code is fairly minimal.

In the argument of Typescript vs. Flow, I definitely agree that for a library to be consumed by other things (React vs. Angular 2 aside), Typescript might not be a sensible choice. I actually thought afterwards that it might be more prudent to keep the tests in plain javascript as that's where the majority of the bugs would occur (in the consumer's javascript).

Flow on the other hand slots into the babel lifecycle a bit better (read: not at all for Typescript). I did find Typescript's type inference was better than Flow's and I found myself having to work around a few of the quirks. For example, flow did not think action was a callable function when it was called here until i specifically typed it to a Thunk.

It also isn't as strict as Typescript and allows some things through. An example of this is providing additional parameters to function calls. Typescript makes you remove them unless you provide specific overrides that handle them. Flow allows them by default which leads to confusing calls and a messier codebase.

Having said all that, I feel like Flow is a good balance for the people that prefer strictly typed systems (like myself) and those that don't (like @vivian-farrell, I assume).

from redux-subspace.

mpeyper avatar mpeyper commented on June 7, 2024

I'm closing this as it was more of a thought exercise and discussion point than actually wanting static types in subspace

from redux-subspace.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.