Cons of using compound componentsHow to export React component with props?React functional stateless component, PureComponent, Component; what are the differences and when should we use what?Typescript React: Access component property typesReact Higher Order ComponentsReact-redux tutorial : Where does children come fromExternal component with consts interfaces in reactReact : best way to Import / ExportImporting propTypes from external file in React StyleguidistGetting component propTypes as stringHow to split a component and keep props working
Character descriptions
SOQL Not Recognizing Field?
How is water heavier than petrol, even though its molecular weight is less than petrol?
Passing multiple files through stdin (over ssh)
SQL counting distinct over partition
Is counterpoint still used today?
Were Alexander the Great and Hephaestion lovers?
Taxi Services at Didcot
How can I get an unreasonable manager to approve time off?
Recommended tools for graphs and charts
Is it legal for a bar bouncer to conficaste a fake ID
Should an arbiter claim draw at a K+R vs K+R endgame?
What do abbreviations in movie scripts stand for?
What language is software running on the ISS written in?
English word for "product of tinkering"
Is open-sourcing the code of a webapp not recommended?
Why doesn't Adrian Toomes give up Spider-Man's identity?
Preventing employees from either switching to competitors or opening their own business
Winning Strategy for the Magician and his Apprentice
Grover algorithm for a database search: where is the quantum advantage?
Compiling C files on Ubuntu and using the executable on Windows
Overlapping String-Blocks
What can I, as a user, do about offensive reviews in App Store?
Medieval flying castle propulsion
Cons of using compound components
How to export React component with props?React functional stateless component, PureComponent, Component; what are the differences and when should we use what?Typescript React: Access component property typesReact Higher Order ComponentsReact-redux tutorial : Where does children come fromExternal component with consts interfaces in reactReact : best way to Import / ExportImporting propTypes from external file in React StyleguidistGetting component propTypes as stringHow to split a component and keep props working
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
I have a simple components:
const Sidebar = (props) => ...
const SidebarLink = (props) => ...
To avoid bloat in import
s I want to do simple namespacing:
Sidebar.propTypes = propTypes
Sidebar.Link = SidebarLink
export default Sidebar
And use it like:
<Sidebar>
<Sidebar.Link>...</Sidebar.Link>
<Sidebar.Link>...</Sidebar.Link>
<Sidebar.Link>...</Sidebar.Link>
</Sidebar>
Question:
Are there any cons for this approach?
Can somethings go wrong?
Is it fine as a whole?
Thanks
javascript reactjs
add a comment |
I have a simple components:
const Sidebar = (props) => ...
const SidebarLink = (props) => ...
To avoid bloat in import
s I want to do simple namespacing:
Sidebar.propTypes = propTypes
Sidebar.Link = SidebarLink
export default Sidebar
And use it like:
<Sidebar>
<Sidebar.Link>...</Sidebar.Link>
<Sidebar.Link>...</Sidebar.Link>
<Sidebar.Link>...</Sidebar.Link>
</Sidebar>
Question:
Are there any cons for this approach?
Can somethings go wrong?
Is it fine as a whole?
Thanks
javascript reactjs
add a comment |
I have a simple components:
const Sidebar = (props) => ...
const SidebarLink = (props) => ...
To avoid bloat in import
s I want to do simple namespacing:
Sidebar.propTypes = propTypes
Sidebar.Link = SidebarLink
export default Sidebar
And use it like:
<Sidebar>
<Sidebar.Link>...</Sidebar.Link>
<Sidebar.Link>...</Sidebar.Link>
<Sidebar.Link>...</Sidebar.Link>
</Sidebar>
Question:
Are there any cons for this approach?
Can somethings go wrong?
Is it fine as a whole?
Thanks
javascript reactjs
I have a simple components:
const Sidebar = (props) => ...
const SidebarLink = (props) => ...
To avoid bloat in import
s I want to do simple namespacing:
Sidebar.propTypes = propTypes
Sidebar.Link = SidebarLink
export default Sidebar
And use it like:
<Sidebar>
<Sidebar.Link>...</Sidebar.Link>
<Sidebar.Link>...</Sidebar.Link>
<Sidebar.Link>...</Sidebar.Link>
</Sidebar>
Question:
Are there any cons for this approach?
Can somethings go wrong?
Is it fine as a whole?
Thanks
javascript reactjs
javascript reactjs
edited Mar 24 at 16:53
Dez
3,41263139
3,41263139
asked Mar 22 at 14:06
streletssstreletss
2,553526
2,553526
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Personally I find it generally adds more complexity than they are worth, but this article discusses som potential upsides and drawbacks on using sub-components in React in more detail. Article found here.
add a comment |
I have used this approach quite often when I was earliest stage of learning React.
Here's how I did:
export const Sidebar = (props) => ...
export const SidebarLink = (props) => ...
And when we needed to use them:
import * as Sidebar from '...' // path to the exports
<Sidebar.Sidebar>
<Sidebar.SidebarLink>...</Sidebar.Link>
<Sidebar.SidebarLink>...</Sidebar.Link>
<Sidebar.SidebarLink>...</Sidebar.Link>
</Sidebar.Sidebar>
But it looks a little uglier in your case. Here's what I'd have used this approach: (Just an example)
<Sidebar.ExportOne />
<Sidebar.ExportTwo />
<Sidebar.ExportThree />
When I used this approach exactly?
I used this approach whenever I need to use several components:
// ComponentOne.js
export const ComponentOne = () =>
// ComponentTwo.js
export const ComponentTwo = () =>
// ComponentThree.js
export const ComponentThree = () =>
// ...
// ComponentIndex.js
export ComponentOne from 'ComponentOne'
export ComponentTwo from 'ComponentTwo'
// ...
And now using it in separate component. So, it's be better to import all rather than using import statement a huge number of lines:
import * as ComponentAll from 'ComponentIndex'
<ComponentAll.ComponentOne />
<ComponentAll.ComponentTwo />
...
But obviously, there's one big con while using this approach, this will impact on performance. Continue reading below to see it why:
You'll be importing all of the components even though, you'll not be using some component. For eg.:
// PlaceOne.js
<ComponentAll.ComponentOne />
<ComponentAll.ComponentThree />
// PlaceTwo.js
<ComponentAll.ComponentTwo />
<ComponentAll.ComponentFive />
So, you're importing all exported components in the PlaceOne.js
and PlaceTwo.js
.
To avoid this con, use import statement like:
import
ComponentOne,
ComponentTwo,
// ... import only required component
from 'ComponentIndex'
// Now, you can simply use:
<ComponentOne />
<ComponentTwo />
This concludes that using <ComponentOne />
rather than <ComponentAll.ComponentOne />
is better approach. And also, we will not loose code splitting advantage while using <ComponentOne />
approach.
2
Together with importing code that might not be used, code splitting advantages are lost.
– Dez
Mar 24 at 16:56
Thanks for your time, but what do you mean by "this will impact on performance"? Bundler performance? It doesn't matter in my case cuz there is no sense to useSidebar.Link
withoutSidebar
– streletss
Mar 24 at 18:05
@streletss Performance I meant for that importing all but using some. In your case, there'll be no effect since you're using all imported component.
– Bhojendra Rauniyar
Mar 25 at 1:53
add a comment |
The pros and cons of certain methods are subjective, in my opinion it is better to export both components because i don't think there is an overhead in doing so. Considering component reuse, or code maintenance if something were to change as well as the tendency to follow this approach for larger components,
I wouldn't recommend this approach even for simple components.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55301391%2fcons-of-using-compound-components%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Personally I find it generally adds more complexity than they are worth, but this article discusses som potential upsides and drawbacks on using sub-components in React in more detail. Article found here.
add a comment |
Personally I find it generally adds more complexity than they are worth, but this article discusses som potential upsides and drawbacks on using sub-components in React in more detail. Article found here.
add a comment |
Personally I find it generally adds more complexity than they are worth, but this article discusses som potential upsides and drawbacks on using sub-components in React in more detail. Article found here.
Personally I find it generally adds more complexity than they are worth, but this article discusses som potential upsides and drawbacks on using sub-components in React in more detail. Article found here.
edited Mar 25 at 17:08
dince12
2,5593723
2,5593723
answered Mar 25 at 17:03
jensmtgjensmtg
513519
513519
add a comment |
add a comment |
I have used this approach quite often when I was earliest stage of learning React.
Here's how I did:
export const Sidebar = (props) => ...
export const SidebarLink = (props) => ...
And when we needed to use them:
import * as Sidebar from '...' // path to the exports
<Sidebar.Sidebar>
<Sidebar.SidebarLink>...</Sidebar.Link>
<Sidebar.SidebarLink>...</Sidebar.Link>
<Sidebar.SidebarLink>...</Sidebar.Link>
</Sidebar.Sidebar>
But it looks a little uglier in your case. Here's what I'd have used this approach: (Just an example)
<Sidebar.ExportOne />
<Sidebar.ExportTwo />
<Sidebar.ExportThree />
When I used this approach exactly?
I used this approach whenever I need to use several components:
// ComponentOne.js
export const ComponentOne = () =>
// ComponentTwo.js
export const ComponentTwo = () =>
// ComponentThree.js
export const ComponentThree = () =>
// ...
// ComponentIndex.js
export ComponentOne from 'ComponentOne'
export ComponentTwo from 'ComponentTwo'
// ...
And now using it in separate component. So, it's be better to import all rather than using import statement a huge number of lines:
import * as ComponentAll from 'ComponentIndex'
<ComponentAll.ComponentOne />
<ComponentAll.ComponentTwo />
...
But obviously, there's one big con while using this approach, this will impact on performance. Continue reading below to see it why:
You'll be importing all of the components even though, you'll not be using some component. For eg.:
// PlaceOne.js
<ComponentAll.ComponentOne />
<ComponentAll.ComponentThree />
// PlaceTwo.js
<ComponentAll.ComponentTwo />
<ComponentAll.ComponentFive />
So, you're importing all exported components in the PlaceOne.js
and PlaceTwo.js
.
To avoid this con, use import statement like:
import
ComponentOne,
ComponentTwo,
// ... import only required component
from 'ComponentIndex'
// Now, you can simply use:
<ComponentOne />
<ComponentTwo />
This concludes that using <ComponentOne />
rather than <ComponentAll.ComponentOne />
is better approach. And also, we will not loose code splitting advantage while using <ComponentOne />
approach.
2
Together with importing code that might not be used, code splitting advantages are lost.
– Dez
Mar 24 at 16:56
Thanks for your time, but what do you mean by "this will impact on performance"? Bundler performance? It doesn't matter in my case cuz there is no sense to useSidebar.Link
withoutSidebar
– streletss
Mar 24 at 18:05
@streletss Performance I meant for that importing all but using some. In your case, there'll be no effect since you're using all imported component.
– Bhojendra Rauniyar
Mar 25 at 1:53
add a comment |
I have used this approach quite often when I was earliest stage of learning React.
Here's how I did:
export const Sidebar = (props) => ...
export const SidebarLink = (props) => ...
And when we needed to use them:
import * as Sidebar from '...' // path to the exports
<Sidebar.Sidebar>
<Sidebar.SidebarLink>...</Sidebar.Link>
<Sidebar.SidebarLink>...</Sidebar.Link>
<Sidebar.SidebarLink>...</Sidebar.Link>
</Sidebar.Sidebar>
But it looks a little uglier in your case. Here's what I'd have used this approach: (Just an example)
<Sidebar.ExportOne />
<Sidebar.ExportTwo />
<Sidebar.ExportThree />
When I used this approach exactly?
I used this approach whenever I need to use several components:
// ComponentOne.js
export const ComponentOne = () =>
// ComponentTwo.js
export const ComponentTwo = () =>
// ComponentThree.js
export const ComponentThree = () =>
// ...
// ComponentIndex.js
export ComponentOne from 'ComponentOne'
export ComponentTwo from 'ComponentTwo'
// ...
And now using it in separate component. So, it's be better to import all rather than using import statement a huge number of lines:
import * as ComponentAll from 'ComponentIndex'
<ComponentAll.ComponentOne />
<ComponentAll.ComponentTwo />
...
But obviously, there's one big con while using this approach, this will impact on performance. Continue reading below to see it why:
You'll be importing all of the components even though, you'll not be using some component. For eg.:
// PlaceOne.js
<ComponentAll.ComponentOne />
<ComponentAll.ComponentThree />
// PlaceTwo.js
<ComponentAll.ComponentTwo />
<ComponentAll.ComponentFive />
So, you're importing all exported components in the PlaceOne.js
and PlaceTwo.js
.
To avoid this con, use import statement like:
import
ComponentOne,
ComponentTwo,
// ... import only required component
from 'ComponentIndex'
// Now, you can simply use:
<ComponentOne />
<ComponentTwo />
This concludes that using <ComponentOne />
rather than <ComponentAll.ComponentOne />
is better approach. And also, we will not loose code splitting advantage while using <ComponentOne />
approach.
2
Together with importing code that might not be used, code splitting advantages are lost.
– Dez
Mar 24 at 16:56
Thanks for your time, but what do you mean by "this will impact on performance"? Bundler performance? It doesn't matter in my case cuz there is no sense to useSidebar.Link
withoutSidebar
– streletss
Mar 24 at 18:05
@streletss Performance I meant for that importing all but using some. In your case, there'll be no effect since you're using all imported component.
– Bhojendra Rauniyar
Mar 25 at 1:53
add a comment |
I have used this approach quite often when I was earliest stage of learning React.
Here's how I did:
export const Sidebar = (props) => ...
export const SidebarLink = (props) => ...
And when we needed to use them:
import * as Sidebar from '...' // path to the exports
<Sidebar.Sidebar>
<Sidebar.SidebarLink>...</Sidebar.Link>
<Sidebar.SidebarLink>...</Sidebar.Link>
<Sidebar.SidebarLink>...</Sidebar.Link>
</Sidebar.Sidebar>
But it looks a little uglier in your case. Here's what I'd have used this approach: (Just an example)
<Sidebar.ExportOne />
<Sidebar.ExportTwo />
<Sidebar.ExportThree />
When I used this approach exactly?
I used this approach whenever I need to use several components:
// ComponentOne.js
export const ComponentOne = () =>
// ComponentTwo.js
export const ComponentTwo = () =>
// ComponentThree.js
export const ComponentThree = () =>
// ...
// ComponentIndex.js
export ComponentOne from 'ComponentOne'
export ComponentTwo from 'ComponentTwo'
// ...
And now using it in separate component. So, it's be better to import all rather than using import statement a huge number of lines:
import * as ComponentAll from 'ComponentIndex'
<ComponentAll.ComponentOne />
<ComponentAll.ComponentTwo />
...
But obviously, there's one big con while using this approach, this will impact on performance. Continue reading below to see it why:
You'll be importing all of the components even though, you'll not be using some component. For eg.:
// PlaceOne.js
<ComponentAll.ComponentOne />
<ComponentAll.ComponentThree />
// PlaceTwo.js
<ComponentAll.ComponentTwo />
<ComponentAll.ComponentFive />
So, you're importing all exported components in the PlaceOne.js
and PlaceTwo.js
.
To avoid this con, use import statement like:
import
ComponentOne,
ComponentTwo,
// ... import only required component
from 'ComponentIndex'
// Now, you can simply use:
<ComponentOne />
<ComponentTwo />
This concludes that using <ComponentOne />
rather than <ComponentAll.ComponentOne />
is better approach. And also, we will not loose code splitting advantage while using <ComponentOne />
approach.
I have used this approach quite often when I was earliest stage of learning React.
Here's how I did:
export const Sidebar = (props) => ...
export const SidebarLink = (props) => ...
And when we needed to use them:
import * as Sidebar from '...' // path to the exports
<Sidebar.Sidebar>
<Sidebar.SidebarLink>...</Sidebar.Link>
<Sidebar.SidebarLink>...</Sidebar.Link>
<Sidebar.SidebarLink>...</Sidebar.Link>
</Sidebar.Sidebar>
But it looks a little uglier in your case. Here's what I'd have used this approach: (Just an example)
<Sidebar.ExportOne />
<Sidebar.ExportTwo />
<Sidebar.ExportThree />
When I used this approach exactly?
I used this approach whenever I need to use several components:
// ComponentOne.js
export const ComponentOne = () =>
// ComponentTwo.js
export const ComponentTwo = () =>
// ComponentThree.js
export const ComponentThree = () =>
// ...
// ComponentIndex.js
export ComponentOne from 'ComponentOne'
export ComponentTwo from 'ComponentTwo'
// ...
And now using it in separate component. So, it's be better to import all rather than using import statement a huge number of lines:
import * as ComponentAll from 'ComponentIndex'
<ComponentAll.ComponentOne />
<ComponentAll.ComponentTwo />
...
But obviously, there's one big con while using this approach, this will impact on performance. Continue reading below to see it why:
You'll be importing all of the components even though, you'll not be using some component. For eg.:
// PlaceOne.js
<ComponentAll.ComponentOne />
<ComponentAll.ComponentThree />
// PlaceTwo.js
<ComponentAll.ComponentTwo />
<ComponentAll.ComponentFive />
So, you're importing all exported components in the PlaceOne.js
and PlaceTwo.js
.
To avoid this con, use import statement like:
import
ComponentOne,
ComponentTwo,
// ... import only required component
from 'ComponentIndex'
// Now, you can simply use:
<ComponentOne />
<ComponentTwo />
This concludes that using <ComponentOne />
rather than <ComponentAll.ComponentOne />
is better approach. And also, we will not loose code splitting advantage while using <ComponentOne />
approach.
edited Mar 24 at 17:08
answered Mar 24 at 16:18
Bhojendra RauniyarBhojendra Rauniyar
54.1k2285140
54.1k2285140
2
Together with importing code that might not be used, code splitting advantages are lost.
– Dez
Mar 24 at 16:56
Thanks for your time, but what do you mean by "this will impact on performance"? Bundler performance? It doesn't matter in my case cuz there is no sense to useSidebar.Link
withoutSidebar
– streletss
Mar 24 at 18:05
@streletss Performance I meant for that importing all but using some. In your case, there'll be no effect since you're using all imported component.
– Bhojendra Rauniyar
Mar 25 at 1:53
add a comment |
2
Together with importing code that might not be used, code splitting advantages are lost.
– Dez
Mar 24 at 16:56
Thanks for your time, but what do you mean by "this will impact on performance"? Bundler performance? It doesn't matter in my case cuz there is no sense to useSidebar.Link
withoutSidebar
– streletss
Mar 24 at 18:05
@streletss Performance I meant for that importing all but using some. In your case, there'll be no effect since you're using all imported component.
– Bhojendra Rauniyar
Mar 25 at 1:53
2
2
Together with importing code that might not be used, code splitting advantages are lost.
– Dez
Mar 24 at 16:56
Together with importing code that might not be used, code splitting advantages are lost.
– Dez
Mar 24 at 16:56
Thanks for your time, but what do you mean by "this will impact on performance"? Bundler performance? It doesn't matter in my case cuz there is no sense to use
Sidebar.Link
without Sidebar
– streletss
Mar 24 at 18:05
Thanks for your time, but what do you mean by "this will impact on performance"? Bundler performance? It doesn't matter in my case cuz there is no sense to use
Sidebar.Link
without Sidebar
– streletss
Mar 24 at 18:05
@streletss Performance I meant for that importing all but using some. In your case, there'll be no effect since you're using all imported component.
– Bhojendra Rauniyar
Mar 25 at 1:53
@streletss Performance I meant for that importing all but using some. In your case, there'll be no effect since you're using all imported component.
– Bhojendra Rauniyar
Mar 25 at 1:53
add a comment |
The pros and cons of certain methods are subjective, in my opinion it is better to export both components because i don't think there is an overhead in doing so. Considering component reuse, or code maintenance if something were to change as well as the tendency to follow this approach for larger components,
I wouldn't recommend this approach even for simple components.
add a comment |
The pros and cons of certain methods are subjective, in my opinion it is better to export both components because i don't think there is an overhead in doing so. Considering component reuse, or code maintenance if something were to change as well as the tendency to follow this approach for larger components,
I wouldn't recommend this approach even for simple components.
add a comment |
The pros and cons of certain methods are subjective, in my opinion it is better to export both components because i don't think there is an overhead in doing so. Considering component reuse, or code maintenance if something were to change as well as the tendency to follow this approach for larger components,
I wouldn't recommend this approach even for simple components.
The pros and cons of certain methods are subjective, in my opinion it is better to export both components because i don't think there is an overhead in doing so. Considering component reuse, or code maintenance if something were to change as well as the tendency to follow this approach for larger components,
I wouldn't recommend this approach even for simple components.
answered Mar 24 at 16:44
mark edosamark edosa
564
564
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55301391%2fcons-of-using-compound-components%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown