You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rather than having 3 components (BasicCodeSection, CodeSection, RemoteCodeSection),
we could - at user-level - offer a unique interface CodeSection with a strategy attribute.
Expected behavior
<code-sectionstrategy="basic">
// some code here, no metadatas parsing ...
</code-section><code-section>
// implicitly, default strategy is "local"
// metadatas parsing
</code-section><code-sectionstrategy="remote" url="url/to/the/code/example"></code-section>
Internal details
code-section becomes a placeholder for underlying technical components :
BasicCodeSection
LocalCodeSection
RemoteCodeSection
It provides only some basic html-element parsing, then :
Design option 1 : Is replaced by the underlying one ?
Design option 2 : Is empty and spawn a child-elements which is the underlying one ?
Additional considerations
We might wanna keep the components named in the previous section still accessible on the user-side for explicit usage purpose
Context
Rather than having 3 components (
BasicCodeSection
,CodeSection
,RemoteCodeSection
),we could - at user-level - offer a unique interface
CodeSection
with a strategy attribute.Expected behavior
Internal details
code-section
becomes a placeholder for underlying technical components :BasicCodeSection
LocalCodeSection
RemoteCodeSection
It provides only some basic html-element parsing, then :
Additional considerations
We might wanna keep the components named in the previous section still accessible on the user-side for explicit usage purpose
Design option 2 allow dynamic component replacement.
The text was updated successfully, but these errors were encountered: