We started out with following dependencies that are injected
(from) and now added dependencies that are merely required to
be drafted first (after).
This also adds further support for part-level configuration.
Restructured code a bit to handle all part-level config in one call.
Removed check in shorthand for debug as it's no longer used.
Updated tests to not fall over on different error message format in
newer NodeJS versions
Just call `pattern.addPart()` and pass it either:
- a part object with all it entails
- a draft method as first and name as second parameter
This will overwrite any existing parts without any warning
This is very rough around the edges, but it's kinda working, so
I'm committing this now.
What this enabled is the ability to extend a part by importing
only that part and then just saying you want a part `from` the
imported one.
The imported part comes with all options, it does not currently
come with all measurements.
This also *follows* dependencies. For example in Brian, we never
explicitly add the base and sleevecap parts, they are simply
added automatically because other parts are buily *from* them.
Best to look at the source code of designs/brian and designs/aaron
to understand what's going on and how it is different.
This is the first commit to tackle some exploratory work
in the context of discussion #2538 that deals with a number
of things, such as:
- Making it easier to attach parts to designs
- Making it easier to attach parts at run-time
- Simplify part inheritance into other designs
- Find ways to handle dependenices across designs
- Find ways to keep the part-specific config with the part
In this initial commit, I've update the Design constructor to
handle two different ways of calling it:
- legacy: new Design(config, plugins, conditionalPlugins)
- 2022: new Design(config)
I didn't want to call this the `new` way because that doesn't
age well, so I went with `legacy` and `2022` and this is how I
will refer to them from now on.
This is very much a work in progress and while I will create a PR
to keep on eye on the tests, I don't expect to merge this as-is.
Currently we check in many different places whether debug is enabled
prior to raising a debug event.
This changes that to always raise debug, but let the debug.raise()
method only store it on the pattern object if/when debug is
enabled.
The Draft react component would load the snippets that are part of our
plugin bundle. However, any additional snippets that are created by
plugins would not not get added to the `defs` section, and thus not
be rendered.
This changes the behavior by doing two things:
- in `core` it adds an SVG object to the renderProps, and makes
sure to run the `preRender` hook on this SVG object prior to
returning the renderProps. This way, svg.defs now holds all
defs, including any that may have been added by custom plugins
- in the `Draft` component, we no longer add a list of predefined
snippets to the defs section, but instead just use the svg.defs
section verbatim. This removes any discrepancies in how SVG
rendering and React rendering handles the defs section of the
SVG document, and thus displays snippets.
Plugins can pass a configuration object (or any
sort of data) when loaded with `pattern.use()`.
We use to set that parameter to `false` when loading, but
now we leave it `undefined`. This makes is easy for plugins
to use a default parameter for the configuration/data passed
to it.
