Releasing v1.0?

[merobal]

As there wasn't any update in the past 1,5 years, what do you think about merging all open PRs related to dependency upgrades (or manually update to the latest) and then release v1.0.0 on npm?

[jeffijoe]

I want to upgrade to MobX 6 first but since I haven't started using it myself yet I have to hold off.

As for dependency updates, LibX only depends directly on mobx-utils, all others are devDeps or peerDeps so those can safely be ignored. With that said, when I do get back to it I will upgrade them.

[MilanCancarevic]

@jeffijoe
Hey, any news regarding this?

[jeffijoe]

We still haven't upgraded yet, and I wouldn't feel comfortable releasing a 1.0 with MobX 6 without extensively testing it on my own code first. Really sorry about that.

We have been using the latest released version for a long time though, so it should be safe to use in its' current form!

If anyone is open to trying it out on a MobX 6 project that would help too!

I just want to clarify that the project has not been abandoned, we are actively using it at Taxfyle and have been using it for the past 5 years. 😄

[jeffijoe]

Hey guys, just an update. I released LibX v1.0.0-alpha.3 which includes support for MobX v6. I have an overhaul planned for the collection and model stuff to better support idiomatic MobX v6 without decorators, but that'll have to be for another day.

[yogeshjain999]

hey @jeffijoe , thanks for supporting v6 🍻

We were doing an upgrade in our app and found that v6 recommends calling makeObservable(this) in the constructor of mobx specific classes.

I was looking at the updated tests here but couldn't find any reference of calling makeObservable(this). Does that mean v1.0.0-alpha.3 can work without calling it ?

[jeffijoe]

Hey @yogeshjain999, thanks for the question !

Assuming you inherit from Model, you will have to add either makeObservable or extendObservable or makeAutoObservable in your subclasses. Typically, we will define a Model in our app's codebase that inherits from LibX's model where our choice is made. I didn't want LibX to make that choice for everyone.

The tests didn't need to be updated because there were no tests relying on a model's properties being reactive (as LibX does not need that internally to function).

Example:

class M extends Model {
  @observable hello: string

  constructor(attributes?: IObjectHash, options?: IModelOptions) {
    super(attributes, options)
    makeObservable(this)
  }
}

const m = new M({ hello: 'world' })
let lastRun = ''
autorun(() => {
  lastRun = m.hello
})

m.set({ hello: 'everyone' })
expect(lastRun).toBe('everyone')

[yogeshjain999]

Understood, thanks @jeffijoe!

When we upgraded mobx to v6 in our app where we inherit all stores from Model and which uses 1.0.0-alpha.2, I found one weird issue with makeObservable(this).

class M extends Model {
  @observable hello: string

  constructor(attributes?: IObjectHash, options?: IModelOptions) {
    super(attributes, options)
    makeObservable(this)

    // I had to call `set` explicitly after `makeObservable` in order update observed fields.
    // Otherwise, `hello` from given `attributes` was not getting considered.
    this.set(attributes)
  }
}

But in case of 1.0.0-alpha.3, there doesn't seem to be need of explicit set which is great!

[yogeshjain999]

Ah wait, I think explicit set is needed when we define annotations without decorator pattern

// In tsconfig.json
"compilerOptions": {
  ...
  "useDefineForClassFields": true,
}

class M extends Model {
  hello: string

  constructor(attributes?: IObjectHash, options?: IModelOptions) {
    super(attributes, options)
    makeObservable(this, {
      hello: observable
    })
  }
}

const m = new M({ hello: 'world' })
expect(m.hello).toBe('world') // This fails because `m.hello` is undefined

[jeffijoe]

Interesting; I haven't used that configuration before.

In our projects, we actually did away with calling set in the base class and no longer accept attributes or options through the constructor; the constructor is used for injecting dependencies instead of a big root store.

We wrap the collection like so:

  const collectionInstance = libxCollection<T>({
    ...(collectionOpts as any),
    create: (attributes: Partial<A>) => {
      const opts = {
        stripUndefined: true,
        parse: true as const,
      }
      const instance = collectionOpts.create()
      // Explicitly calling `set` after creation.
      instance.set(attributes, opts)
      return instance
    },
    update: (existing, input) => existing.set(input, setOpts),
  }) as Collection<A, T>

Example of how we use it; each parameter passed to new Job() is something that'll reach into another store somewhere, rather than injecting the entire root store.

  jobs = collection<JobDTO, Job>({
    create: () =>
      new Job(
        this.primeWorkspace,
        this.primeMember,
        this.primeConversation,
        this.primeTeam,
        this.primePublishedLegend,
        this.getTeamMember,
        this.getCurrentMember,
        this.canRemoveCollaborator
      ),
  })

[yogeshjain999]

Aha that's cool! We kind of do similar thing where we've multiple stores defined instead of single root store. They can initialize one or more collections as required.

I see in your example that there is an explicit set being called after instance creation, so that makes sense!
Thanks for clarifying it 🍻

[jeffijoe]

I'll be releasing 1.0.0-alpha.4 soon which updates dependencies, and also exports an ESM build + gets rid of Lodash. See #45