Sticky Nav Header with React Hooks and IntersectionObserver API - reactjs

Basically my goal is to translate this StickyNav implementation to ReactJS and keep the cross-browser compatibility:
https://codepen.io/smashingmag/pen/XWRXVXQ
The main problem I have is to find the proper way to implement the direction and prevYPosition variables with react hooks.
I added all my setup for the IntersectionObserver and the rest of the helper methods within a useEffect hook, and tried to store the values for direction and prevYPosition using useState.
But when I add those variables to the useEffect dependencies it's causing the component to re-render multiple times and the original logic simply doesn't work.
So, what I did as my first implementation attempt was to store the direction and prevYPosition variables in the actual header (bc I had a reference to that node thru useRef). But it doesn't fulfill all the use cases. It works properly when you scroll up and down. But when you click on a link element on the Nav trying to jump from section 1 to section 4 it doesn't work as expected. You can see that implementation here:
https://codesandbox.io/s/react-sticky-nav-i4e0y
I would highly appreciate if someone can provide me some guidance on how to approach this implementation to make it work properly with react js.
Thank you very much in advance!

From your question, i thought you are facing problem with the scrolling. so use debounce to resolve this issue.
Some of the debounce sources are:
Lodash debounce - https://lodash.com/docs/#debounce
useDebounce hook - https://usehooks.com/useDebounce/

Related

Is it fine if useContext has many useState in React

I am working using useContext in React. Today, I recognized that I am using too many useState in useContext. I was looking for the answer, but I could not find it.
I know it is a silly question, but please answer my question if possible.
Thank you.
Thank you for the answers to my question. So, I understand that if there will be many states in useContext, it is a good way to use useRedux.
This is my opinion. I think there is no such thing as too much as long as your states are relevant with what you are doing. It depends on what is your purpose when using the createContext. But make sure to organize them well so that they are still modular and not mixed with other context of states.
For me, I draw a simple borderline where if I'm only making some one-off reusable components that need control from far away (e.g. Dialog which can be toggled by deeply nested button), then I should create a context that has just enough states for that component. Whereas if I want to store some states which I want to access from multiple places, especially if it is related to business logic, then I prefer to use Redux instead.
I think useContext and useState are different functions:
useContext: This is a hook that returns values from the context that has been kept. Any change in values causes the react component where this hook is placed to rerender.
useState: a hook that declares the react component's state.
I think I understand what you mean when you say you declare many states in the context. Some best practices you need to consider are:
Using useReducer hook to group & manage the change of states. It makes it easier to control the changing of states. It is obvious that the state shifts with each individual action.
You need to review the total state that is declared. Only keep states that need to be shared in that context.
Refer: read more in react js docs about context api & declare a state in react component.

react custom hooks vs normal functions, what is the difference

I'm trying to wrap my head around custom hooks. I understand normal hooks which is just fine, but my question is, when writing a custom hook, what is the difference between that and a normal function? I mean why not call it a normal function instead of calling it something like use*
I believe no one has answered your question exactly. I'm still also understanding the benefits and purpose of having this extra feature called hooks, but I can still share my understanding.
React Hooks are JS functions with the power of react, it means that you can add some logic that you could also add into a normal JS function, but also you will be able to use the native hooks like useState, useEffect, etc, to power up that logic, to add it state, or add it side effects, memoization or more.
So I believe hooks are a really good thing to manage the logic of the components in a isolated way.
So, you could have a foo.component.js (UI), a useFoo.js(logic), where useFoo will contain maybe many js functions and one hook to manage that functions and return what it's supposed.
This is an amazing video about react hooks, fully recommended
https://youtu.be/J-g9ZJha8FE
There are some differences and problems that make us use react custom hooks:
First of all, if you use normal functions, with every re-render of the component, this function will be created again and it causes the lack of performance. you may think that it can be fixed by using useCallBack and make react not to create a new function every time it re-renders but it is not the main problem that we are going to solve.
The main problem as the react document has discussed with a brief example of tracking online friends, is avoiding copy-pasting the same logic in different functional components which they need to be stateful too.
If we use normal functions inside a component and use useCallBack to avoid creating a new function every time, we did not solve the problem because in every component we should also copy this logic so this did not solve the problem.
The other solution is to make a function outside the functional component to handle this logic, but there is a big problem: in a normal function outside of the component, we don't have access to states because as we mentioned, this implemented logic is stateful and we have access to states only in react components.
So what is the solution here? yes, Custom React Hooks!
It is a stateful function that uses other react built-in hooks (e.g. useState, useCallback etc.) that can wrap around the stateful logic that you wanted to gather in one place and avoid copy and pasting the same logic in multiple components.
With this approach, you can put your logic outside of the component in another function while you are getting the benefit of stateful functionalities of react.
I hope that this answer may solve your problem and resolve your ambiguity.
From the React docs:
A custom Hook is a JavaScript function whose name starts with ”use” and that may call other Hooks. [...] Its name should always start with "use" so that you can tell at a glance that the rules of Hooks apply to it.
So why define custom Hooks with a special "use" naming prefix?
1.) It tells consumers, that these functions are intended to be used with React and obey to an implicit contract (above mentioned rules).
2.) You can have tooling support which checks and enforces these rules. For example, eslint-plugin-react-hooks utilizes a heuristic that assumes, a function starting with "use" prefix and a capital letter after it is a Hook.
React Hooks (custom or non-custom) should start with the use prefix. As well as, as per the React Documentation:
1) Hooks should be called from the React code only not from the Regular JS functions. Hence, Hooks' scope is limited to the React code world and has more power to do a lot with React code. Rather than JS, regular functions could be used across application but as react code guidelines keep the code more aligned to react syntax.
2) In the class-based components, the Hooks won't work but regular functions will.
3) In the regular JS functions, you can't access useState, useEffect, useContext etc. but in react custom hooks I can.
A custom hook depends on one more other hooks. By design React hooks are meant to be used from a component's render method. You will get a warning if you try to use a hook anywhere else. Custom hooks follow the same convention as built-in hooks because they have to be used in the same fashion. The use prefix is just a convention to identify hook functions which are usually call at the very top of a component render method.
You can name your hook function anything you want but as I mentioned, you will get a warning from React if used outside of a render method.
You can call it whatever and it will still work fine. The only advantage is that if you use the “useName” convention, React will check for error whether it correctly follows the rules of hooks. It just makes your task slightly easier.
As other users have stated custom hooks or hooks, in general, are used where we have to do anything related to react component while other util functions are not tied to react state and won't work is areas where react state logic is in place.
An example of custom hooks be useCustomNavigation which could a list of navigator function like navigateToHome, navigateToCheckout etc. So when you to route to homepage from different parts of code, we just use this hook. Also any logic/feature like analytics, and side effects could be part of navigateToHome function.
An example of Util function could be anything like capitalize which does not has to do anything with react or react component. You cannot create a util function called navigator and add useNavigation.
As I see it, custom hooks have their own specific purpose and have their own characteristics and approach.
What I mean is that in certain cases we would want to create a custom hook and not a function.
For example, if you have a need to store some data in the Localstorage you would want to create a custom hook for that and call it "useLocalStorage" and if you want to create a component, let's say a page form, you would want to write a function component.
Difference being that our hook is not a component and shows nothing on our UI.
It is simply a logical operation.
The reason I see them as different other than the "logical" example above is that our custom hooks are unique in a way of allowing the usage of other custom hook related hooks. For example, the "useDebugValue" which can only work in a custom hook.
What is weird to me is the way React differentiates a function from a custom hook, which I think is the main cause of the confusion.
It "checks" your function name and if it starts with "use" then it's a custom hook. What I think would have been a better option is to change the "const" declaration to a "hook" declaration or give it a unique type.
TL;DR, custom hooks are the logic and will allow the usage of hooks like "useDebugValue" and our functions are mostly UI related.

React spring swipeable example without hook

Hello I'm trying to rewrite the swipeable cards example without hook (using render props), however I stuck in how to communicate Gesture with Spring. appreciate any help.
This is the official example with Hooks: https://codesandbox.io/embed/j0y0vpz59
This is my code trying to replicate the example with render props https://codesandbox.io/s/4j45p88qkw
what I'm unclear is the bind function, once I computed the new x rot scale, how to I pass it to the card?
This example came from this discussion: https://spectrum.chat/react-spring/general/how-to-flick-something-off-the-screen-using-react-spring~37848d54-55ba-4a74-9a98-9aa42041177d Someone converted the hooks example, here's the thing running in codesandbox: https://codesandbox.io/s/jnoqzplmj9
I would recommend hooks, though. There is nothing like it, renderprops start to have severe limits since they're mantling the view, while hooks are basically utility functions that bear no relation to any view, which makes it easier to combine them with things like gestures and so on.

how to emulate .transition from D3 in Angular or React

All:
I wonder if I want to do data visualization using React JSX or Angular template to replace D3 DOM manipulation (such as .enter().append() .exit().remove()), how can I implement the animation transition like .transition().duration() in either of them?
For example, I build a line chart, in d3 after I change data set and generate new path, there is animation for those line to transform
Thanks
So, the problem with using D3.js in React is that both want control of the DOM, right?
D3 wants to directly select elements, add elements or remove elements based on the data being used, and add attributes to those elements.
React likes to have everything represented in it's virtual DOM and doesn't like any changes to the actual DOM without it's consent.
After some research, some people try utilizing some of React's different life cycle methods to instigate specific D3 methods at different points in a components life. For example, one approach wants you to return false to ComponentWillUpdate and use functional side-effects to run the D3 code on the actual DOM. While this works for some cases, it's still an improper use of React, and you're losing out on the benefits of passing state to any children components that component may be rendering.
I would suggest researching some of these approaches of how people have tried to tackle the issue, to see the root of the problem.
Also, feel free to try out this library my friends and I made that allows you to plug in your existing D3 code as is, and returns React components, and handles transitions, animations, timers, etc.
http://react-d3-library.github.io/
Always looking for more feedback!

forceUpdate VS forceReload

I'm wondering what is the difference between forceUpdate() and forceReload() in ReactJS.
Tried to find some documentation about that but couldn't find some on forceReload()-
Thanks in advance!
Not sure where you saw it, but forceReload isn't a part of React. You presumably couldn't find documentation because there isn't any -- if I search for "forceReload" react right now, this question comes up first.
If you want to make a component rerender without changing its state or props, you should call forceUpdate.

Resources