Conversation
There's a lot of complicated logic here in order to maintain backward compatibility. It's possible to isolate this completely in rom/compat though, which is what I'll do before 6.0.0 release. In general, components will be able to provide their default config using a very simple interface, so it will be completely generic. Basically as long as a component responds to `config` method and it returns a Hash-like object, then default settings will be resolved automatically. All the class attributes will be replaced by this and moved to rom/compat.
7b48548 to
1c5efaf
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds a generic component API which is the culmination of all the previous refactorings/improvements/cleanups. There's still a lot of additional complexity caused by backward-compatiblity but this will be cleaned up and moved to rom/compat eventually.
The important part is that IT WORKS 😆
Up until now, setting up rom could be a challenge, reasons were plenty and due to various limitations caused by the internals, it was hard to make it better. All the limitations are removed now and the entire system is way, way, WAY more flexible to the point that I can't even believe that it was possible.
Anyhow, the main idea behind rom-rb was always to be a toolkit that consists of a bunch of decoupled components that can be put together. It should be easy to use rom-rb for simple stuff, but it should be also easy to use rom-rb for advanced stuff.
Following this huge goal, this PR enables using rom-rb as if it was "Lego for persistence". You can start with a single class and define everything you need there and because most components can be inferred, this can be automated in 99%.
Examples
UPDATE: this particular API was extracted into a separate branch because this PR would become too big (it's already huge).
Here's an example of defining a custom class that is rom-enabled and it defines a relation with its schema explicitly. We
auto_migrateso that the db schema is established automatically for us. Everything else is fully dynamic and automated:Eventually, you'll be able to define any component type like that and either use your standalone rom-enabled objects, or provide a single rom setup like you used to.