From ab3f71829af02e096b4302b7e9dcdc7cebfb9674 Mon Sep 17 00:00:00 2001 From: Simon Katan Date: Wed, 28 Feb 2024 16:38:28 +0000 Subject: [PATCH] Update src/docs/tipsForReusableCode.mdx Co-authored-by: James Sheasby Thomas --- src/docs/tipsForReusableCode.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/docs/tipsForReusableCode.mdx b/src/docs/tipsForReusableCode.mdx index 8d814ff3..5ad87a62 100644 --- a/src/docs/tipsForReusableCode.mdx +++ b/src/docs/tipsForReusableCode.mdx @@ -45,7 +45,7 @@ In all cases your component will be a function composed of other atoms, molecule ### Decomposition - In the most complex cases you might want to decompose the existing component into smaller components. This will then allow you to recompose them, replacing only the parts you want to change. -- An example of this is `OakCheckBox` and `OakQuizCheckBox` which are ccomposed of `InternalCheckBox`,`InternalCheckBoxLabel` and `InternalCheckBoxWrapper` . This allows the `OakQuizCheckBox` to have a different layout and behaviour to the `OakCheckBox` but with the same underlying functionality. +- An example of this is `OakCheckBox` and `OakQuizCheckBox` which are composed of `InternalCheckBox`,`InternalCheckBoxLabel` and `InternalCheckBoxWrapper` . This allows the `OakQuizCheckBox` to have a different layout and behaviour to the `OakCheckBox`, but with the same underlying functionality. - This is probably the most robust method but the most labour intensive as it involves refactoring the existing component. - Some risks to look out for are: - poor discoverability: make sure the decomposed components are named in relation to what they should compose. Follow [naming conventions](/docs/docs-namingconventions--docs) \ No newline at end of file