Here is the case: I want to reuse a panel/callout/tooltip to display different content while I really do not want React to render multiple same DOMs. A code sample maybe look like below:
<SingletonTooltip />
<SingletonTooltip />
<SingletonTooltip />
And it will render 3 icons/buttons in the place I declare them but only renders one tooltip DOM when I click one of these icons/buttons.
A workaround I am not really into is:
<TooltipIcon />
<TooltipIcon />
<TooltipIcon />
...
<TooltipContent />
which brings extra effort to use and maintain code.
I have tried to save the instance in the state of component. However, this will make the component disconnected from the property passed by its parent.
Maybe React context will help? Looking forward to your guys suggestion.
Why not make one component that renders all the buttons and then only renders one content element based off which one was clicked? let each button invoke an onClick handler which is given to it as a prop and then use this to render only what you need. if you implemented some global state management solution you could use even allow more elements place content into the content element
Related
In my REACT application, I'm trying to render a Component programmatically, but pasing to it any REACT context. Let me show you a simple example with this sandbox: https://codesandbox.io/s/kind-carson-u0hup?file=/src/App.tsx
As you can see, what I want to do is rendering <Dialog> programmatically when I click a button. But, inside that <Dialog>, I want to use any context created on the React Tree.
Unfortunately, I am aware that React.render does not pass any context, thus this cannot work: if you click on the button, you will see that, while the context in <InnerComponent> provides the value 'FooBar'. inside <Dialog> I have the default value 'initialValue'.
Thus, the question is, is there any way I can programmatically render a component, AND passing to its any kind of context?
I'm aware that React.createPortal does pass the context, but that method MUST be called inside the return statement of a component, while instead, in my case, I render the <Dialog> after a click on the Button.
Also, yes, I could always have the <Dialog> rendered, and use a prop isVisible.. But this is a simpler example.
I've read several things (some of these in the following links), but none of these really helped me:
https://github.com/facebook/react/issues/17974
Is it possible to pass context into a component instantiated with ReactDOM.render?
Why component rendered with ReactDOM.render loses react-redux context (Provider)
You can not put the render of component outside of your ContextProvider.
Check this link:
https://codesandbox.io/s/busy-curran-pbz6p?file=/src/App.tsx:0-834
I am struggling with atoms in atomic design. Why would I need to make a component for already estabilished HTML UI element? Isn't it redundant?
Lets say I have a button, in molecule instead of using the <button>Label</button> I would be force to use component <Button myOwnLabel="Label" /> inside which is just rendered the same old button.
I can't see the benefit of making another file. Can you help me see it?
Thank you.
There is nothing wrong with using <button> in React. I use it all the time for some small projects that do not require having complicated components for each element.
The benefit of atomic design orientation in React is to give you a consistent foundation for every element in your app.
For example, in your project, all buttons are blue, and every time someone clicks on them, an event is sent to Google Analytics. Using pure HTML elements, you will declare it as:
<button className="blue" onClick={sendEvent}>Text<button>
If you have 100 buttons, you will have to write this configuration 100 times.
Moreover, one day, you may decide that it is not useful to track clicks anymore, and you need to remove the default onClick event on 100 of them.
Then your designer says, let's change all buttons to orange, and you repeat the whole process again.
That's when using custom element comes in play. You can declare the above code in a separate <Button> component.
const Button = () => <button className="blue" onClick={sendEvent}>Text<button>
It appears as simple as <Button> everywhere else, but the actual content of the <Button> is dynamic. Any update will require you change the code inside the component only. For the above example, to achieve all the change requirements, you only need to change <Button> to
const Button = () => <button className="orange">Text<button>
and it will be reflected in all of its instances.
Hope this helps.
There is a tile (molecule) with an image, some text and a play button. When the button is triggered a video should be shown via a modal. I think a modal should be an organism, but i want the modal to be part of the tile, which is an molecule.
The modal should be part of the tile, because its easier to use it that way.
I dont want always wire them up from inside an other organism, template or view.
Should i make the modal to a moclecule or should i make the tile to an organism?
Any advice?
I know this is an old question, but I recently stumbled on this while trying to figure out basically the same thing and wanted to add my two cents.
Note: I just started learning about atomic design, so this could be completely wrong - Take it for what it is, an opinion.
Brief background
In my case, I have a component (lets call it Form A) which is going to live inside of Modal A. Modal A is a very simple modal which is more of just a dialog modal (basically just contains open/close functionality) but it happens to have a form inside of it in this case.
Since the Modal technically contains a form (molecule) visually, I initially figured this must be considered an organism, or at the very least, another molecule.
My Solution
After thinking on this for a while, and referring to https://atomicdesign.bradfrost.com/chapter-2/ for guidance, in my instance the following sentence made it clear for me. (in my opinion)
These atoms include basic HTML elements like form labels, inputs, buttons, and others that can’t be broken down any further without ceasing to be functional."
In my mind, going by this logic, I can break my modal down all the way to the atomic level...
If I remove the Form A component from the modal content, the modal is still functional (just has no content). To me, this tells me that I should in fact make a general Modal component and label it as an atom.
After I have a Modal atom component, I can simply pass it children to change the content of the modal. This allows me to easily have a Modal A, Modal B, Modal C component which in my opinion would then be an organism since at that point it is implementing the molecules to create a larger component.
Possible Answer?
So, if I were going to try to answer your question while using my own logic:
I would personally create a simple general re-usable modal component as an atom, then I would create an organism, say <PlayVideo /> which has inside of it the
<Modal props={modalSpecificProps}>
<Video />
{any other content to display in the modal}
</Modal>
With <Video /> being a child along with whatever else should be displayed inside the modal.
The only thing I would say I'm still unsure about myself is, can something be an atom, but still technically allow children to be placed in the atom as well?
Anyways, food for thought for anyone else that stumbles across this.
This Is more of a "theoretical" question that often buffles me in different situations and use cases, I will give a simple example to demonstrate it.
Let's say I have a list of 10 buttons.
Everrytime I click a button, a floating menu appears on top of the clicked button - there is only one menu visible for any given time.
Let's assume that I can't render this floating menu within the button component and I can only render it in the buttons parent level (meaning that this menu is sibling to those buttons).
I have 2 possible options to do that:
Keep the x,y position of the last clicked button and render the menu in this given position
Render the menu once and using "ref" to directly relocate the menu
On the one hand, the first approach seems more "Reactish". On the other hand, the possible implemention I can think of is pretty ugly (capturing the clicked item position and saving it to state which triggers defender), and further more, I am not so sure about re re rendering the whole container just because I need to move a small piece of it.
The second approach touches the DOM directly using refs. Although possible , doing DOM manipulations sometimes feel bad to me.
Is there a better approach? Which of the 2 makes more sense?
Any suggestion or thoughts will be appreciated!
Thanks
React uses whats called a virtual DOM, which is a representation of the DOM, that sits on top of the real browser DOM. Whenever you update state or a user performs an action the virtual DOM compares and checks the changes with the real DOM and then updates the UI accordingly.
So if certain DOM elements like a are not different between changes it does not get re rendered, only the DOM elements that have changed are re rendered. And if a property on a DOM element is changed, only the property is updated and the DOM element is not re rendered.
<div color="blue" />
to
<div color="red" />
The whole element is not destroyed and re created, only the property is changed.
However if the element in the host tree is different than the entire host tree is destroyed and recreated.
<div />
to
<p>
This is refereed to as reconciliation
https://reactjs.org/docs/reconciliation.html
So using refs is definitely more of a hacky solution since its more of an escape hatch and directly manipulates the DOM.
I would definitely stick with option 1, I think there is an elegant solution to the use case you described, it would involve just adding a click event listener in the componentDidMount and keeping track of the click position that way.
And also its hard to say without code but since your buttons will be the same, they will not be re rendered only the menu will.
Would recommend for further reading
https://overreacted.io/react-as-a-ui-runtime/
I've designed a pretty simple responsive layout (be sure to open link with Chrome) and now I'm trying to implement it in React. I've attached some screenshots of the layout as well.
This app is supposed to be the typical tab/nav app, but due to the responsive layout, the view hierarchy is pretty awkward to work with in React.
I've built a React component called Layout to abstract away all the layout stuff. Layout also has props for renderLeft, renderRight, title, and onTab. Layout's children are then rendered into the content block.
The easy solution would be to make Layout a child of the current view and render whatever you want. However, this is going to mess up some animations I had in mind. I want to have a CSSTransitionGroup element wrapped around the tabbar, the title, and the left and right buttons animating them as they change. Thus, the Layout element must remain the same between the views else a new CSSTransitionGroup element will be rendered for each view which isn't good.
So now the problem is that I have a Layout component with a view rendered as its child (but sort of as sibling with respect to the App component), but the view needs to specify renderLeft, renderRight and title for the Layout which is its parent! For example, in the top-level App component, the render function may look like the following, and I need some way of setting Layout's renderLeft from the View.
render() {
return (
<Layout renderLeft={??}>
<View setRenderLeft={??}/>
<Layout/>
)
}
The only thing I've thought of so far seems totally like the wrong way of doing it:
In the top-level App component, have a state variables for renderLeft, renderRight, and title and App passes those to the Layout props. Now for the view, pass some functions like setRenderLeft, setRenderRight, and setTitle which will change the App state and thus change the Layout. We can thus call these functions in componentWillMount for each view.
This just seems like a total hack and seems to break the whole idea of one-directional-data-flow. However, I'm not sure how else to do it! Are there any more proper ways of doing this? I'm reminded of the concept of delegation when building iOS apps, but thats very OOP and not very FP.
Any ideas?
Your question is a little difficult to tell exactly what the issue is, however if I were you I would read up on https://facebook.github.io/react/tips/communicate-between-components.html
For communication between two components that don't have a
parent-child relationship, you can set up your own global event
system. Subscribe to events in componentDidMount(), unsubscribe in
componentWillUnmount(), and call setState() when you receive an event.
Flux pattern is one of the possible ways to arrange this.
You want to either have the siblings talk to the parent and communicate there, or at the global level.
Hope this helps.