GithubHelp home page GithubHelp logo

Comments (5)

crimx avatar crimx commented on May 22, 2024 2

I've investigated the mobx-state-tree before adopting mobx to Flat. I think it won't solve our issues.

  1. We don't need snapshots and runtime type checking which are the main selling functionalities of mobx-state-tree.
  2. It adds another layer of concept complexity and runtime overhead which Flat doesn't need.
  3. It offers poor supports for async await. You need to write generators for async actions which looks quite nasty.

from flat.

BlackHole1 avatar BlackHole1 commented on May 22, 2024

after an internal team discussion, we felt that this feature should not go first.

our core problem is that the existing mobx Store is difficult to maintain.

the reflect-metadata is just a solution to try to solve the problem, but it should not be finalized directly, but should be researched first to see if there are other solutions to solve the problem.

currently mobx v6 does not recommend using decorators anymore, I think we should use the official recommendation (makeObservable / makeAutoObservable) (Although we are using these right now...)


Let me elaborate on the current pain points of our mobx Store:

1

class TestStroe {
    constructor() {
        makeObservable(this, {
            value: observable,
            double: computed,
            increment: action,
            fetch: flow,
        });

        // imagine that there are more than 400 lines of code

        // when I get here, how do I know if it's `computed` or `ref`?
        // the frustrating thing is that you have absolutely no idea! 
        // you need to scroll your mouse until you see `makeObservable` and you can confirm
        double() {
            // code...
        }
    }
}

2

our Store is too big! So big that you can open any Store file and feel a deep sense of despair...

they should have had the opportunity to split into more granular Stores...

from flat.

crimx avatar crimx commented on May 22, 2024

We may address the issues by enforcing naming convention and further splitting stores.

from flat.

BlackHole1 avatar BlackHole1 commented on May 22, 2024

can mobx-state-tree solve our problem?

cc @crimx @l1shen

from flat.

stale avatar stale commented on May 22, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from flat.

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.