Library's state and future

[kettanaito]

Hello, folks. I think an update is due regarding this library's status and future.

I've been in the progress of rewriting Data for some time now, and it's going to be a full rewrite ground-up. On the bright side, it will fix a bunch of issues and bring in a long-awaited functionality, like type-safe models, static models, more powerful relationships (incl. polymorphic ones), and so forth. The downside is that this kind of rewrite takes time.

I consider the current version of Data to be in maintenance mode. I will do my best to review and merge critical fixes but I won't be accepting new features as you must have noticed in the pending queue of pull requests. This is the best strategy for this library to evolve and also for me to keep its maintenance sensible. Thanks for understanding.

[themagickoala]

Hi @kettanaito, are you working on this rewrite independently? I'm sure there would be plenty of people willing to help if you want to open-source the process!

[kettanaito]

@themagickoala, I plan to open the pull request eventually so others can join the effort! I didn't go that route initially because it was a full rewrite from scratch in an empty repo. That's how my mind performs best sometimes. Once I'm at a stable point, I want to open a pull request here but it will be a complete rug-pull: old code deleted, new code taking its place. This isn't incremental really but I'm doing my best to find the way to develop the software in my free time.

[themagickoala]

Sounds great, looking forward to the PR!

[kettanaito]

I hope to spend some time on Data at the beginning of next year. I'm quite busy until the end of this year but if I get a chance, I will publish the V2 WIP as a pull request here.

[kettanaito]

I think I've finally refined the modeling API to adopt in 2.0. It will look something like this:

class User extends Model {
  // Identifiers.
  @id id = uuid()

  // Plain properties with default value.
  name = 'John'

  // Foreign keys.
  @foreignKey(Comment)
  commentIds: ForeignKey<Comment>[]

  // Relationships over foreign keys.
  @manyOf(Comment, { by: 'commentIds' }
  comments: Comment[]
}

class Comment extends Model {
  @id id = uuid()
  text = 'Default comment text here'
}

Working to see whether this API will suit all the use cases. Looking good so far.

[wyozi]

Would be nice if creating custom handlers was easier in v2 as well. I'd like to work on a PostgREST handler, but effectively waiting for v2 for that

[kettanaito]

Update

The rewrite of Data is in a good state. There are a few design decisions to make regarding relationships in the context of using decorators, and I'm exploring possibilities there.

That being said, I'm not working on the rewrite at the moment. I spent a few weeks in January on it and since then I've been focusing on other things. I'm looking forward to coming back to Data later this year. I cannot give any ETAs because an unemployed engineer my working schedule is unpredictable.

Thanks for your patience.

Why don't you open source the rewrite so others can contribute?

Because I'd still have to supervise and review those contributions, for which I don't have time. It sucks to see great pull requests hanging there forever. This pressures me more than it pressures you to wait for the rewrite.

[kettanaito]

How can we help?

I'd appreciate a discussion around relationship definition. In particular, circular relationship definition:

• User.post -> manyOf(Post)
• Post.author -> oneOf(User)

These cannot be achieved by direct class references as one class will ultimately be referenced before it's defined, which is a no-op:

class User {
  @manyOf(Post)
  posts
}

class Post {
  @oneOf(User)
  author
}

What other tools do for this is make the class references lazy by wrapping them in a function:

class User {
  @manyOf(() => Post)
  posts
}

class Post {
  @oneOf(() => User)
  author
}

This delegates the reference to the runtime and this will resolve correctly.

What do you think about this syntax? What caveats do you see when using it?

[SalahAdDin]

Sounds great, looking forward to the PR!

It seems to be dead.

[themagickoala]

@kettanaito I think circular references are important to have. It's something we are missing in the current version. The lazy syntax feels a bit clumsy but I'm not sure I see a better option!

[kettanaito]

@themagickoala, the current version supports circular references because you reference models by name, not their value.

factory({
  user: {
    posts: manyOf('post')
  },
  post: {
    author: oneOf('user')
  }
})

The references to 'post' and 'user' are resolved on runtime, making such a circular dependency possible.

With the new syntax, I'd much rather you pointed to a model's class, which allows us to infer more things from it (such as its primary key to provide in the relationship). I agree, it seems the lazy reference is the only way to do this in JavaScript. I dislike the syntax as well.

[Matt-McConway]

How can we help?

I'd appreciate a discussion around relationship definition. In particular, circular relationship definition:

• User.post -> manyOf(Post)
• Post.author -> oneOf(User)

These cannot be achieved by direct class references as one class will ultimately be referenced before it's defined, which is a no-op:

class User {
  @manyOf(Post)
  posts
}

class Post {
  @oneOf(User)
  author
}

What other tools do for this is make the class references lazy by wrapping them in a function:

class User {
  @manyOf(() => Post)
  posts
}

class Post {
  @oneOf(() => User)
  author
}

This delegates the reference to the runtime and this will resolve correctly.

What do you think about this syntax? What caveats do you see when using it?

Pretty new to MSW but for what it's worth this seems like the best approach. Little weird syntax wise, but like you said the reference to the class itself is more valuable than the 'stringly' typed alternative

[kettanaito]

That lazy syntax is also how other tools in the genre solve the circular reference problem. TypeORM as an example.