What's remaining for a 0.1 release?

[pavanpodila]

I think feature wise, it's looking solid. Curious if there is anything sorely pending for a 0.1 release. At this point I see only the following:

• Finalize features for 0.1 and harden them with more tests
• Update Readme
• Update the website with API docs and guidance for building larger apps
• Add few more examples
• Anything else...

What say @katis, @rrousselGit ?

[smiLLe]

Hey guys. i am actively following this repo for a while and i am pretty sure, as soon as people start using mobx and especially @rrousselGit hooks implementation one of these question will pop up:
"how to navigate/show dialog/show snackbar", "am i allowed to use context" .... [in (use)autorun, (use)when].

[rrousselGit]

State change of mobx stores are made when the widget tree is unlocked (not building).
As such, listeners (and therefore hooks) can freely call setState and use the context API.

Like so:

Widget build(BuildContext context) {
  final store = Store.of(context);
  useReaction(() => store.currentRoute, () {
    Navigator.pushNamed(context, store.currentRoute);
  });

  return Container();
}

[katis]

We could also do a 0.0.x-dev release before documentation is done, so that the bravest can easily test the packages with their own code. I found a weird case in my own app that made the whole thing lock up, but I could not reliably repeat it, or find the minimal test case and it would be good to see if anyone else runs into that issue before we do the real release.

[pavanpodila]

A lock up could have happened if you have some cyclic dependency. May be diagnose the dependency tree? We should also catch that in code. Right now, we are missing this check. I'll add an issue for that

[Update]: Added a new issue #99

[marcoms]

Currently it doesn't seem clear how to create observables from non-primitive values. I've figured out from the examples that I can use ObservableList for lists (couldn't regular Lists be wrapped automatically by @observable as in MobX.js?), but I'm not sure how I would do this for custom types.

[pavanpodila]

For custom types, you could just create a Store, like we do for the Todos example. You can mark the properties you want as @observable.

You can have a plain List as @observable, in which case it will react only when the reference to the list changes. With an ObservableList, it will also react when the length changes, when items are added/removed. We deliberately don't convert a List to an ObservableList when you mark a List as @Observable

[pcg92]

Is this feature available?

Pass { deep: false } as 3rd argument to disable the auto conversion of property values

What about asReference and asFlat?

[pavanpodila]

These are not needed in the dart world. By default all observables are shallow and by reference.

[pavanpodila]

I am planning to push a 0.1 release soon. The website and docs are mostly in place. There will be ongoing additions. However I feel the community is ready to consume the packages. Please share any concerns. @katis , @rrousselGit ?

mobx, flutter_mobx and mobx_codegen will be set to 0.1. After that they can go about their own release cycles.

[pavanpodila]

0.1 has been published.