flutter_mobx project

[katis]

Created flutter_mobx and a vanilla Flutter Observer component.

Still need to check the mono_repo stuff on a non-Windows computer.

[rrousselGit]

I still see the momo_repo files even after them being theorically removed.
Is that normal?

[katis]

No, they need to be removed

[katis]

@pavanpodila I got this to build on Travis, it runs package get, analysis and tests. I just can't figure out how to add Coveralls.

Travis config now has 2 env configs that makes it run separate builds for the packages:

env:
  - PACKAGE=mobx
  - PACKAGE=flutter_mobx FLUTTER=true

Now we would need to somehow send different Coveralls reports from these I guess?

[katis]

Codecov seems to support the monorepo use case https://docs.codecov.io/docs/flags

[pavanpodila]

Let's try codecov. I am not attached to coveralls, just that the dart_coveralls had an easy integration. If we can find such a package, we are good to go 👍

[katis]

@pavanpodila I had to let codecov request access to mobxjs organization, not sure who has to accept it?

[pavanpodila]

@pavanpodila I had to let codecov request access to mobxjs organization, not sure who has to accept it?

I've asked @mweststrate, who is the owner to approve.

[mweststrate]

Approved. Note that it needed access to private repositories as well, that is a little strange? (not really a problem atm, since there are none) Op ma 14 jan. 2019 om 03:30 schreef Pavan Podila <notifications@github.com>:

…

@pavanpodila <https://github.com/pavanpodila> I had to let codecov request access to mobxjs organization, not sure who has to accept it? I've asked @mweststrate <https://github.com/mweststrate>, who is the owner to approve. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#34 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvGhPfvyjA9335wrHR09fnn4PlIkhAvks5vC-u3gaJpZM4Z4PIF> .

[pavanpodila]

Thanks @mweststrate. I think coveralls had the same requirement ?

[pavanpodila]

@katis Wondering if we even need a DerivationTracker. Why not use the Reaction directly, now that we can expose the {start, end}Tracking as separate calls? 🤔

[katis]

Frankly, I really don't like using the start/endTracking methods anywhere. The track(callback) interface is a superior one from a safety point of view. Consider a function like this:

foo() async {
  tracker.startTracking();
  await doSomethingAsync();
  tracker.endTracking();
}

Here the tracking starts, doSomethingAsync is called, returning a Future and the method is suspended. Then the Dart runtime schedules something else to execute while waiting the Future to resolve, making mobx track all sorts of random things. You can't create a mess like this with the callback interface. This is why the only place to use it should be the useObserver hook...

I think I'll figure a way to expose Reaction.track properly and use that instead here, for the above reasons, but I'll do it in a separate PR.

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@29f2129). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master      #34   +/-   ##
=========================================
  Coverage          ?   97.61%           
=========================================
  Files             ?       18           
  Lines             ?      670           
  Branches          ?        0           
=========================================
  Hits              ?      654           
  Misses            ?       16           
  Partials          ?        0

Flag	Coverage Δ
#flutter_mobx	100% <100%> (?)
#mobx	97.54% <ø> (?)

Impacted Files	Coverage Δ
flutter_mobx/lib/flutter_mobx.dart	100% <100%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 29f2129...11bc9bc. Read the comment docs.

[pavanpodila]

Loving the codecov report 🏆 😃

[katis]

@pavanpodila This should be ready for review now. I'm not sure that the codecov config is perfect, but I think we can fix issues if/when they happen.

[katis]

@mweststrate I also sent a request for adding a better integration with codecov to the repo

[mweststrate]

Approved! Op ma 14 jan. 2019 om 17:42 schreef katis <notifications@github.com>:

…

@mweststrate <https://github.com/mweststrate> I also sent a request for adding a better integration with codecov to the repo — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#34 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvGhOarozkz1Vz5PsnawOrC6h7eGGUZks5vDLOOgaJpZM4Z4PIF> .