tomasz-zablocki
commented
5 years ago Redux-ORM has a clearly defined purpose and what it does, it does exceptionally well - it practically removes what is arguably the least exciting part of redux experience.
At the same time, it did not fall into use redux without touching redux camp, staying true to core redux principles and concepts.
There's actually very small cognitive effort required to start using redux-orm's entire feature set (documentation aside)
The high-level things are fine: valid purpose, no-redux friction, clear responsibility, streamlined setup and integration. There's merit in keeping these unchanged.
Scope
We need criteria to determine which type of features we will work on and accept. My suggestion:
- State management for Redux-based use cases
- Schema-based definition of an object-relational map
- Automatic update of relationship accessors
- Simple query definition and fast resolution
:+1:
My two cents:
I think that it would be beneficial to start thinking about a pre-1.0 release schedule: put two boards up, collect the issues into backlog, move it around, plan what's when and roll out few minor version bumps before 1.0.
Currently it's hard to tell when some of the features are going to be released or if they are going to be released at all.
The second thing after documentation, that is holding redux-orm back, is TS support.
Now, I know this had been discussed before and I understand the rationale for not having package-bundled types. There are other reasons I can think of on top of original ones so that's fine.
Regardless of that, there's no reason for redux-orm not having a first-class TS support. There's a huge group of users that will simply miss-out on the library, because they are not able to integrate it or the integration is shoddy.
Due to the nature of the library, providing types is pretty challenging, but there are few non-breaking library tweaks, which would improve the typing process tremendously.
Principles
Guide users when they make mistakes
- Always strive to improve documentation
:+1: I also think that the auxiliary stuff like example projects should become Redux-ORM org repositories and their contents kept up-to-date with library state.
- Prefer taking shortcuts to prevent mistakes over relying on documentation
This is unclear to me.
Strive for high code quality
- Always test new features and bugs
:+1:
There's extra confidence instilled by 
PR's should not hinder coverage.
- Leave enough whitespace and name things precisely and concisely (clean code)
:+1:
Follow widely accepted UX design principles
- Apply progressive disclosure in API design
:+1:
- Resemble major backend ORMs for familiarity
:+1: starting with the ability to explicitly declare fields for backwards relation
First of all, in light of the recent discussion in #209 I apologize if I have disrespected the common understanding of our goals with Redux-ORM. The following has been on my mind ever since and I would like to discuss with you important points regarding the future of this project.
Scope
We need criteria to determine which type of features we will work on and accept. My suggestion:
Principles
How will we judge a PR? Which best practices should contributors follow? Having a set of principles answering these questions will allow us to make objective decisions. I've tried to cut to the chase as much as possible here.
Guide users when they make mistakes
Don't restrict users unnecessarily
Follow widely accepted UX design principles
Strive for high code quality
Please provide feedback if you disagree with something or if you want to add a point. This is all about agreeing on the same core ideas, so it is obviously very subjective.
We should include a final version in the form of Contributing Guidelines (
CONTRIBUTING.md).See also: