I am facing a really nasty issue, I need to create a badge component that it'll be places over a custom component.
This is my first attempt to create something similar in React, with HTML is way easier because you work directly with the DOM.
In this case instead I need to create a badge that will highlight a new component/feature, when you click on it a popup get's open with a bit of text that'll explains what the component is about, aka it's functionality. Telling you this because I need to listen for onClick and it's not possible to use pseudo-elements.
The base idea
<BadgeComponent position="top left">
<CustomComponent />
</BadgeComponent>
Since I can't use a pseudo-element that'll inherit all the element CSS properties this is my thinking:
do not change the CustomComponent because each time could be different
the BadgeComponent is a wrapper that creates a div with position:relative (so I can position the badge wherever I want)
BadgeComponent needs to be display: inline-block otherwise it'll change the overall layout
I need to take the CustomComponent box-model properties, remove from it and apply them to the BadgeComponent. This mostly because margins are messing with the BadgeComponent size and position the badge itself will be trickyer
Basically I need to take the CSS properties of the DOM element rendered from the child component.
The approach
So I've been experimenting with some code before came here and my first attempt has been to dinamically pass a ref to the child component of BadgeComponent with this snippet:
{React.Children.map(this.props.children, (element, idx) => {
if (idx > 0) return; // don't care if it has more childrens, at least for now.
return React.cloneElement(element, { ref: this.newFeature });
})}
I also thought to take the CustomComponent as a prop of BadgeComponent, like so:
<BadgeComponent position="top left" target={ CustomComponent }>
But I didn't (yet) followed this path because I thought that at the end of the day this.props.target it's basically the same of this.props.children and didn't earn anything doing so. Am I right?
I know that in React we have ref to get a reference to the DOM created from a component but in this case is not applicable because I am not applying the ref to the component that renders an HTML, I am applying it to CustomComponent that gets cloned and it doesn't pass to the DOM.
From my experiment everything works fine if I pass an HTML element, in the experimental code I have a div.box that gets the badge in the position that I want but as soon as I pass the Button I got the following error: Window.getComputedStyle: Argument 1 does not implement interface Element.
I am using window.getComputedStyle to get the CSS properties I care about.
My research
I've been looking all around the web and I've seen a nice implementation that, unfortunately, just works with styled components or styled defined inline in <style>. I am looking to not use NPM packages as this one because firstly I believe that it is possible to implement without reach for an additional package and second actually I do not like much the way that the sticky/badge get's implemented (with all respect obviously).
I don't know where to look anymore, I am not an expert JS/React developer (been WP theme developer for 10 years) so probably there is some basic concept that I missunderstand?
I've read about findDOMNode (looks will be deprecated soon) and forwardRef in the React ecosystem but I do not think that's the way to go, am I wrong?
I do not want the copy/paste code, well if you're so gentle to fork the codesandbox and share the solution will be great but I am trying to learn here: there is a way to get a reference of the rendered HTML element from any component?
Thinking that this is the missing part, if I can reach the DOM my code is already working 😊
Related
I am currently using an HTML template and am trying to return those as react components, however when I run the HTML code natively the page looks like this.
However, running the same code being returned by a react component, it is almost as if the components are only taking up half the page. Some of the elements such as the text of the name and collar have been changed but I haven't touched any of the DOM elements so I don't know why the proportions are not correctly outputted. Any advice on how I can combat this issue?
Here are some suggestions:
Check your css.
You have some styling overrides on your react side. Those styles are overriding the ones defined on the html template that you are trying to render. Look for any styling your react app is doing on list items.
Its not exactly a good idea, returning a whole html template from the react component. Since we don't know your use-case, can't give any advice on this.
Try a react component library, if you want to create a similar page using pure react components. Will be a more sensible approach.
I understand that you should not manually manipulate the DOM nodes rendered by a Vue component for reasons including:
After another render, Vue can override any changes you did
It can interfere with Vue's patching algorithm
My use case is I would like to implement a way to move a DOM node to a separately-controlled location for the purpose of displaying it fullscreen. Imagine an editor widget with a fullscreen button that "pops out" the editor and overlays it fullscreen.
I understand that I can achieve this with CSS alone using fixed positioning, but I'm not interested in that, I'm particularly interested in the consequences of moving the DOM node out from wherever it is and appending it directly to the <body> element. Will Vue still be able to patch the nodes correctly after the parent component re-renders?
I have experimented with this already and I have a working implementation, and I haven't encountered any issues yet. Still, this doesn't ease my concern, and the Vue docs don't talk about doing something like this.
What potential issues, if any, might I encounter?
portal-vue is unsuitable because it recreates the component instance each time it is relocated, which I do not want.
Depending on how the component lifecycle works in Vue, moving a component in the DOM might trigger lifecycle methods. E.g. with Custom Elements, moving means triggering disconnectedCallback of the component, and subsequently connectedCallback. This is often where the component initialization takes place.
Rather than moving the component manually from the outside, consider giving the component itself the ability to relocate.
I've been loving checking out styled-components, but getting a bit stuck with the concept of extracting everything out into a component, and how to tweak styles for a particular use case. For example:
<Flex>
<MyStyledTitle>Hello I am a Title</MyStyledTitle>
<MyStyledBodyText>blah</MyStyledBodyText>
</Flex>
Let's say that I wanted to make the following customisations for this use case:
styled title grey (subdued text colour),
the body text to have a right margin of 100px (don't ask why).
The styled-components way, the first part could be done like:
<MyStyledTitle colorTint='subdued' />
or even
<MyStyledTitle>
<SubduedText>MyTitle</SubduedText>
</MyStyledTitle>
Perhaps using a prop for title that lets you configure it to use subdued text or ANOTHER hild component that defines the grey text..
But what about for the second option...
<MyStyledBodyText style={{paddingRight: 100}} />
Inline style? Use a Grid or layout component around it?
At which point does something become a specific styled-component and if not, then how does one customise smaller style changes?
While i really like this idea of removing the mapping between component + class name, I guess i'm feeling a bit torn between the classical idea of having a 'style sheet' file that can contain all the classes and modifier css, then using a presenter to choose between the combinations of css classes.
I might be missing something here, but just keen to see some bigger examples of styled components in practice. Any links / tips would be greatly appreciated!
We've been using styled-components in our project extensively. Few basic patterns/conventions we use are
Components created using StyledComponents are not used across React Components. Under extreme scenarios, we pull them into external files and export.
DIV is the most extensively used styled-component (styled.div). (Ofcourse we do use other html elements like button, table td etc., but styled explicitly).
Different styles for the same HTML element (or) React Component are declared explicitly as different styles. (If you refer to FAQ section of the styled-components docs, you might notice these - https://github.com/styled-components/styled-components/blob/master/docs/faq.md)
Overall to answer your question, we have moved away from the classical stylesheet and as well thinking about combining multiple styles. It has worked well, except that looking up on unit tests is a bit painful.
Thanks
Say you are passing a prop called show to a component. If the prop value is true, you should render the full component normally. If it is false, you should not display anything.
You can do this two ways.
return null in the render method of the component.
apply a CSS class containing display: none attribute to the component's DOM element.
Which ones is the correct or the preferred way?
I do not think there will be any definite answer for this question.
Each approach has its benefits and drawbacks.
With CSS you have:
it might work faster
no need to think about restoring child control states if control is shown again.
With returning null:
the total rendered DOM might be considerably smaller. This is important if you have many such components that might be hidden.
there will be no collisions in rendered html. Lets say you have tabular view. Each tab is its own complex form with many child controls. If you have some raw javascript/jquery/whatever working with their ids/classnames etc. - its quite hard to ensure each tab/form has unique ids, unless you do not render them.
From my point of view the decision will be based upon the structure of your control. If it have complex structure with many nested children and you do not have any means of restoring their states when switched on again - go with CSS, but I would say this is a short term solution for quite simple controls only. In all other cases I would go with not rendering a component.
If you think you would need to display the component again, during that page life, then I would recommend using css way, as the impact on DOM manipulation would be less in that case. In some other cases probably returning null would be more helpful.
For the most part, your two solutions are interchangeable. They both "work" fine.
I would warn against preemptive optimization in choosing which of these methods to choose. If you do need to eventually modify your code and try the other method, this is an absurdly simple swap to make and shouldn't be an obstacle. So don't worry about it until there's a reason to worry about it.
I'm the OP.
If components are hidden depending on the screen size, CSS media queries and display: none works the best if the app is pre-rendered using something like react-snap. This is because, if the pre-rendered device and the viewing device don't match, the layout would change when the app rehydrates if the component hiding logic is in JS.
Related to that, we need to be careful that even though the component is not "shown" with CSS display: none, the component is still there and if there are effects, they will still fire.
Suppose we have two sibling react components called OldContainer and NewContainer. There is a child component inside OldContainer that contains a <video> tag, and the video is currently playing.
The user can now drag the child component (with the video) and drop it in the NewContainer, and they expect the video to keep playing while it's being dragged and after being dropped.
So the video appears to stick to the mouse position, and when dragged and dropped in the new container, it animates to its new position (again, it doesn't get paused).
How would you implement this? Can we implement this in a pure way (in line with the spirit of pure functions)?
Clarification: I could have used some other element instead of a video tag for explaining this problem. A NumberEasing element would be a better example, since it would require the props and state of the component to be preserved during and after the interaction.
Update 1: Code examples obviously would be nice, but what I'm mainly looking for is just a general description of how you would approach this problem in a "functional" way. How do you keep your view code simple and easy to reason about? Who handles the drag-and-drop gesture? How do you model the data that's fed into the views?
Take a look at this library : react-reverse-portal
What is it that you want to preserve? Is it Javascript objects that the component holds as state, or is it state in the DOM (like how long a video has played, or text selection in an input box)?
If it's just Javascript objects as state, you're better of moving the source of that state to another service (something like Flux). That way, it doesn't matter if the component gets recreated because it can be recreated with the state that was there before.
EDIT
The way to keep your view code simple and easy to reason about is to not keep state inside your components. Instead, all data that the component needs should be passed into the component as props. That way, the component is "pure" in that it renders the same output given the same props. That also makes the problem of wanting to reuse a component instance a non-issue, since it doesn't matter when the same input gives the same output.
For drag and drop, I'd suggest looking at: https://github.com/gaearon/react-dnd.
How you model the data you pass to view components is up to you and the needs of your application. The components shouldn't care, they should just expect to get data passed as props, and to render them. But the popular approach to dealing with this is of course Flux, and there are many libraries that implements Flux in different ways.
SECOND EDIT
Regarding if you have a subtree with hundreds of components that you want to move: I'd still start off by making the state external (pure components), and render that tree in a new place. That means that React will probably recreate that entire subtree, which is fine. I wouldn't deviate from that path unless the performance of it turned out to be horrible (just guessing that it might be horrible isn't enough).
If the performance turned out to be horrible, I would wrap that entire subtree in a component that caches the actual DOM tree and reuses it (if it gets passed the same props). But you should only do this when absolutely needed, since it goes against what React tries to do for you.
THIRD EDIT
About gestures: I'd start out with listening to gesture events in componentDidMount, and in the event callback call setState on the component with the coordinates it should have. And then render the component in render with the coordinates given. React won't recreate the component when you call setState but it will re-render it (and diff the output). If the only thing you changed was the coordinates, it should render fast enough.
If that turns out to be too slow, like if the subtree of that component is huge and it becomes a bottleneck to recreate the subtree of vDOM, I'd reposition the DOM node directly in a RAF-loop outside of Reacts control. And I'd also put a huge comment on why that was needed, because it might seem wierd for some other developer later.
Create a new variable using const or var. Put the instance of data using rest spread operator, update the necessary data to pass and send the data to the component without mutating the state of component.
Just like:
const data = {
...this.state.child,
new_data : 'abc'
}