GetDutchie / brick

An intuitive way to work with persistent data in Dart

Home Page:https://getdutchie.github.io/brick/#/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Current state of this project?

fvluijn opened this issue · comments

Hey guys,

First of all: great project! You'd expect the issues solved by this to be more widespread and even natively supported by Flutter.

Anyway, looking at this repository and trying to get it to run (I can't), I'm wondering if this project is abandoned or not?
Do you have plans to maintain it into the foreseeable future? I'd love to help but I'm very new to Flutter and Dart.

I noticed the links on GitHub are old (redirect to your blog), and I can't resolve the deps when following the setup guide:

$ flutter pub get
Because brick_offline_first_with_rest_build <1.0.0 depends on brick_offline_first_abstract ^0.0.8 and brick_offline_first_with_rest_build >=1.0.0 depends on brick_offline_first_abstract ^1.0.0+1, every version of brick_offline_first_with_rest_build requires brick_offline_first_abstract ^0.0.8 or ^1.0.0+1.
Because brick_offline_first_with_rest >=1.0.0 depends on brick_offline_first_abstract ^2.0.0 and brick_offline_first_with_rest <1.0.0 depends on brick_offline_first_abstract ^2.0.0-rc.2, every version of brick_offline_first_with_rest requires brick_offline_first_abstract ^2.0.0-rc.2.
Thus, brick_offline_first_with_rest_build is incompatible with brick_offline_first_with_rest.
So, because test depends on both brick_offline_first_with_rest any and brick_offline_first_with_rest_build any, version solving failed.

And my pubspec (clean new flutter project via Android Studio).

dependencies:
  flutter:
    sdk: flutter
  cupertino_icons: ^1.0.2
  brick_offline_first_with_rest: any

dev_dependencies:
  flutter_test:
    sdk: flutter
  brick_offline_first_with_rest_build: any
  build_runner: any

Flutter 3.0.5, Dart 2.17.5

So any hope I can use this in a production environment?

Cheers!

@fvluijn Hey, this is still being actively maintained. Day-to-day has been shifted to the GraphQL domain, but that's not to say the Rest domain is abandoned. I'll see what I can diagnose about this error tomorrow.

@tshedor that's good to hear. Haven't looked as closely at the GraphQL part, might be interesting to use as well. I'll try and see if those packages do resolve.

Alright, just to confirm the packages do resolve when using the GraphQL packages:

dependencies:
  brick_offline_first_with_graphql: any
dev_dependencies:
  brick_offline_first_with_graphql_build: any
  build_runner: any

@fvluijn sorry for the delay. Turns out I hadn't published brick_offline_first_with_rest_build. v2 is published now, and using any now works for the rest domain. Best of luck with your project, and thanks for opening this issue.

@fvluijn sorry this autoclosed on the PR, but I think we're resolved on this? Please @ me on here if you're still unable to compile dependencies and I'll reopen.

Sorry about the late reply, works like a charm, thanks!

Small follow up, if GraphQL has the focus right now, would you recommend using that over rest when implementing this library?

I would recommend whatever you know best. While GraphQL has more development now, REST has been in the field for years and is tried and true.

Comparing architecture, I don't believe GraphQL is build exactly like it's sold. There are some extremely frustrating parts of GraphQL - like duplicate definitions of inputs and types - and poor interpolation within TS/JS. The selling points of a strongly-typed contract between client and server and offers field-level observation and forces schema tracking are all great.

It's a tool, but it may not be the best tool for your job. Or it may be the best tool. I'm sorry to give you a "it depends" answer.

Not at all, that's a good answer, thank you. I was just thinking your library might favor one or the other.
Thank you for your answers!