There are various tools to help an individual to build animations with ReactJs. But each one has its own shortcomings. Following are the tools that I've explored till now:
ReactCSSTransitionGroup : Quite effective but I don't like how it introduces coupling between CSS and Javascript. For example:
<ReactCSSTransitionGroup
transitionName="example"
transitionEnterTimeout={700}
transitionLeaveTimeout={700}
></ReactCSSTransitionGroup>
Now one needs to add classes like example-enter, example-leave, example-enter-active and example-leave-active in CSS. Not a big fan of this. Besides this is not easy to manage when one is going for complex sequential animations.
ReactMotion : Another powerful tool. Useful for sequential animations as well. But implements them through delays which is not a goo approach for complex animations as introducing new elements into the chain would mean altering the delays for other elements.
ReactTransitionGroup So far my favorite solution. It exposes lifecycle hooks and one can manage the animations using tried and tested libraries like GSAP and managing complex pieces is quite easy. But it works on the DOM nodes and we know that whatever changes React undergoes outside its render method, it is not aware of that. So even though it achieves the desired output, it goes against React's way of working. For example, one can look at this fiddle https://jsfiddle.net/tahirahmed/h68s0zod/ (I didn't make this I stumbled upon it while doing my research.)
I understand that animations happen on DOM nodes and for production environments it makes total sense to use tried and tested solutions like GSAP or VelocityJs or AnimeJs. But how to make sure that all that plays well with React?
P.S. - I have tried solutions like Velocity-React and React-GSAP-Enhancer but they don't seem to get the job done as for sequential animations, they tend to rely on delays and not promises. Besides they do forced updates which is not a good way to go.
I am combining ReactCSSTransitionGroup and styled-components.
So I define all CSS and params inside the "styled component". So anyone who wants to re-use this transition will create <ExampleTransitionGroup> and all params and css are handled inside this componnet.
Related
I'm developing a frontend application that must be responsive at least for desktop and mobile resolutions.
I'm wondering what's the recommended way to structure the codebase.
Searching online various solution I found:
using something like tailwind where in every tag I can specify some "responsive" class which activate only at specific breakpoints
using #media-queries
using libraries like react-responsive
Using approach 1) I feel like the component is very messy and difficult to read: every line, every tag could be rendered or not based on classes applied. Understand what is rendered desktop or mobile side is madness.
Approach 2) is pretty ok but you have the css outside of the component.
Probably it's right to have the css outside the component for someone but I think that react encourage to encapsulate even this kind of aspect inside the component, right?
Approach 3) is basically like the approach 2) but encapsulating it in the component.
What it's not clear to me is:
are these the only approaches that are recommended nowadays?
when using something like 1) or 3) should I create N different version of the same component, where N is the number of breakpoints that I should support? Or the component should be only one with conditional logic that use different styles based on the resolution?
Duplicate the components makes all more clearer to read but has the downside that maintain all these duplicates could be very difficult (every edit, every fix, should be copy-pasted in every component).
At the same time using only one component with "responsive classes" is harder to read even if you have the advantage to maintain only one class.
What do you think?
Thanks
I am using jointJS as a diagramming library. It creates nodes on a graph using svg elements.
I want to use react to render the content of those nodes, and since jointJS lets me configure what svg element i want it to use, all I have to do is
Configure jointJS so it knowns a node is a <foreignObject>
Retrieve that foreign object, and mount a react component inside of it using createPortal
Dynamically size the foreign object so it fits the react component.
It works fine, but I don't have enough experience with foreignObject to know if any caveats are to be expected.
Can anyone provide some feedback about their experience with such practices ?
Answering my own (old) question feels a bit like:
If you're reading this because you're faced with a similar issue, my advice is to avoid being in this situation in the first place.
Some standard CSS features will behave inconsistently, won't work at all, or will have very different outputs depending on the browser you're using.
If I remember correctly, transform and opacity are the two main problematic properties.
Also, animating those properties will rarely work at first try.
Perhaps this is such an edge case that browser bugs are not often found and reported. (and probably not prioritised).
We ended up developing a flowchart library that natively uses react to display nodes.
Cheers!!
As I noticed, it seems create-react-app changed app.js class component based in a function component,
any idea why they did this?
React itself is moving away from class-based components.
A quotes from this doc: Introducing Hooks
In addition to making code reuse and code organization more difficult, we’ve found that classes can be a large barrier to learning React. You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers. Without unstable syntax proposals, the code is very verbose. People can understand props, state, and top-down data flow perfectly well but still struggle with classes. The distinction between function and class components in React and when to use each one leads to disagreements even between experienced React developers.
Additionally, React has been out for about five years, and we want to make sure it stays relevant in the next five years. As Svelte, Angular, Glimmer, and others show, ahead-of-time compilation of components has a lot of future potential. Especially if it’s not limited to templates. Recently, we’ve been experimenting with component folding using Prepack, and we’ve seen promising early results. However, we found that class components can encourage unintentional patterns that make these optimizations fall back to a slower path. Classes present issues for today’s tools, too. For example, classes don’t minify very well, and they make hot reloading flaky and unreliable. We want to present an API that makes it more likely for code to stay on the optimizable path.
To solve these problems, Hooks let you use more of React’s features without classes. Conceptually, React components have always been closer to functions. Hooks embrace functions, but without sacrificing the practical spirit of React. Hooks provide access to imperative escape hatches and don’t require you to learn complex functional or reactive programming techniques.
I started working with React a few months ago. Coming from an Angular background it took a bit to get used to react concepts but I started enjoying it super fast.
Over the past two months I have refactored some class based components to functional components using React hooks. I am looking for advice on some best practices here since I am fairly new to functional hooks and there is not a whole lot of solid opinions on best practices. Here are a few
With regards to “unit” testing. the instance in functional React does not exist. I can’t call a function and test it independent of other methods. React now suggests that “we recommend using react-testing-library which is designed to encourage writing tests that use your components as the end users do.” This approach seems more like end to end testing to me. I have certain functions that that do a number of calculation and save to state without any visual changes and re-rendering. How should I test those functions?
I have read that I need to move some of my functions outside of the main exported function and call them in order to have them return a value to update the state with. Is this good practice? Should I export all of these outside functions in order to be able to test them or is this bad practice? If not how do I get to test these pure functions. I have created a very simple example of the pattern I am talking about here
https://codesandbox.io/embed/busy-currying-v09bb
I would love to know your opinions and how you have managed to solve these problems. Any thoughts or insight
Is much appreciated.
You and I are on same boat as since we both have moved to React from Angular. Considering the points you mentioned I would like to share some practices we have been following in our react projects. This has helped us to reduce much efforts in finding and fixing the bugs. Also we could achieve 100% test coverage.
Always create a common libs and keep all the function which has mostly a business logic but no DOM impacts. This reduces the size of stateful components and makes code much better to deal with unit testing.
Stateful component should never have bulk UI JSX. Always create stateless component (pure component) for UI and handle them all though
the container.
Avoid creating functions which returns the pure HTML (JSX). Crate a different file and return a stateless component from there. This
makes Unit testing easy.
This again is entirely depend on the your project structure. In Angular you work with certain set of pre-defined rules of Angular and Test tools like Protractor makes it easy to test.
However React comes with more flexible development approach which has its own downside. If developer do not keep hold on the way he/she writing the app, it gets into a chaotic situation.
PS: I use JEST for the testing and it does job well in terms of unit testing. I also use cypress for UI automation which is a great tool for react UI automation.
Hope I could help!
All:
I am pretty new to React. A lot of posts talking about React's performance virtualDOM, but I guess I did not quite get it, I kinda wondering how to take advantage of this when it comes to data visualization area(especially with lib as D3.js), almost every operation in data visualization is to modify the data which leads to DOM related operation like style changing or number of elements updating.
For example, say I need to build a line chart to show a time series data, each time when I choose another data set, the line need to be recalculated and drawn or add one more line, I wonder in this situation, how React virtualDOM shows a better performance than D3+Angular( I just try to understand which part of virtualDOM improve the performance in this case, or what part is most time consuming when it comes to real DOM operation)?
Thanks
There is currently no great way to work with React and D3. As you seem to have caught on, this is because in the React world you don't do direct DOM manipulation, but in the d3 world that's the only thing you do. In many ways the whole d3 library is built around direct DOM manipulation if you think about how the d3.selection.data function works. There are many libraries that work well when using D3 for it's mathematical capabilities, but none that have fluidly (and with good performance) mixed React with d3 animations. (For that matter, animations in React in general are a pain.)
Some starting points:
react-d3 is great for drawing easy charts with React. There is also a similar package, react-d3-basic.
react-faux-dom uses a shadow DOM to perform d3 calculations and easy DOM manipulation and then render it out to React, but that doesn't work well with things like Force Layouts since the performance gets bad fast. There is a good blog post on this package.
What you'll notice is that almost all things that are React and d3 are basically just charts. Here is a good example of React and d3 using a Force Layout. However, you'll notice even that small example sometimes doesn't feel fluid.
It seems to me that the current consensus for Force Layouts and the like is to simply drop out of React for those components and let d3 do its thing. This isn't ideal but it's way more performant. I know some people are also investigating the use of react-art for combining React and d3, but I haven't seen a good solution for the Force Layout yet.