Info: Development Philosophy
Super Editor is designed and built with the following philosophies, principles, and rules.
No two text editors are exactly the same. Every client wants their editor to do something different. Super Editor must respect this reality by ensuring that it's configurable at every level.
TODO: insert a few screenshots of editors doing things in different ways
It's easy to combine different things together into what you want, even if it's a bit tedious. But it's difficult, and often impossible, to tear something apart to remove the things you don't want. For this reason, composition is critical. Super Editor must avoid monoliths. The occasional facade is acceptable, but everything beneath the facade must be designed for easy composition within other use-cases. Moreover, facades must exist at the boundary of the system, where clients can choose to avoid them. Facades that exist deeper within the system imply a de facto monolith.
TODO: insert a diagram of monoliths on the boundary vs the interior
The Flutter community likes to debate the concept of "state management". This concept is ill-defined and distracts from real software engineering concerns. This project will never internally incorporate BLoCs, Redux stores, or any other perceived notion of a "state management solution". Instead, Super Editor will model the roles, relationships, rules, and invariants of an extensible text editor.
Every public member must have DartDoc style comments. All comments should concisely communicate the purpose and nature of the class, method, or property in a way that a typical developer is likely to understand.
Most private members should also contain comments. The purpose of comments is to inform and direct other developers who are reading your code. Developers read private code, too. Treat private code with an equal level of respect.
A text editor is UX heavy. Nearly everything a text editor does involves user input and/or visuals. Every feature should include a demo that clearly presents the feature's capabilities.
TODO: insert a GIF of a canonical feature demo
Each demo should be concise, exercising the code needed for the feature and nothing more.
TODO: provide a good vs bad example
The complexity associated with a text editor means that manual testing is exceptionally ineffective. Every contribution to the project needs to include effective tests. Tests should ensure that the most critical features behave as expected, while doing so with the fewest tests possible.
Sooner or later your code will create bugs. We must be able to quickly locate bugs, have confidence that we've found the root cause, and then demonstrate that we've fixed the issue. Always consider opportunities to build tooling that helps us locate and fix bugs.
TODO: insert a few examples of such tools
TODO: add qualifiers about where to define such tools to avoid shipping the tools to end-users