Skip to content
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

Is this library stable? #391

Open
alberto-f opened this issue Jan 21, 2020 · 2 comments
Open

Is this library stable? #391

alberto-f opened this issue Jan 21, 2020 · 2 comments
Labels

Comments

@alberto-f
Copy link

Hello there,

First at all, thank you guys for making this library.

We are considering using this library in production but Im wondering if it is ready for production.

I see the coverage is 100%. Well done!!

Still since the version of this package is in version 0 Im wondering if it has a stable API. Usually version 0.X.Y means that it is not stable yet.

In regards to that, Is version 0.X.Y still under heavy development ? Is this library using sematic versioning?

Thank you for this awesome job!

@cowboyd
Copy link
Member

cowboyd commented Jan 21, 2020

Hi @alberto-f!

Thanks for considering Microstates for your application. As always, the question of whether something is "ready" for production is subjective. We are currently using the released version and it is (as far as we know) bug free, but we do use semver and as you point out, the 0 major version does mean that we do foresee some changes to the API before we're comfortable placing a 1 on it.

Here is the roadmap of the changes we plan on making before 1.0

  1. removing the .state property on primitive microstates, and instead using a .value property for every microstate:

before:

create(Number, 4).state //=> 4
valueOf(create(Object, {})) //=> Object {}

after

create(Number, 4).value //=> 4
create(Object, {}).value //=> Object {}
  1. Atomic values. Currently, each microstate references its own value. We will probably move to an internal representation where each microstate references a path to a location within a single atom held by the top-level microstate. This will allow microstates in one portion of the tree to reference each other without changing the internal structure of the original value. Mostly this will be an invisible change, but it is significant to warrant mention.

  2. 1st class support for TypeScript. It's very important that Microstates work seamlessly with TypeScript. We're not sure what changes will be required here, there's a real possibility that the could be breaking.

  3. We've developed some slightly different patterns for using microstates with the https://github.com/thefrontside/effection.js library which makes some current features that are bundled with microstates (such as the store, and the stable values) optional. It's very possible that we will bundle Store separately in the future. This isn't a breaking change in API other than where you would import it from:

before

import { Store } from 'microstates';

after

import { Store } from `@microstates/store`;

I hope that helps answer your question. The API has been stable for a while now, but will change. However, we are conscientious of semver and would not release breaking changes without at the very least iterating on the minor version number, and once we do reach 1.0 always iterating the major version with a breaking change.

@taras taras pinned this issue Jan 21, 2020
@alberto-f
Copy link
Author

alberto-f commented Jan 23, 2020

Thank you very much for providing this information. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants