cedricdelpoux / cedricdelpoux/react-responsive-masonry
Incosistent behavior
- Dominant language
- JavaScript
- Stars
- 455
- Forks
- 47
- PR merge metrics
- No merged PRs in 30d
Description
Long story short we have an array of div's with an useEffect that uses a Ref, divided into 4 columns using ``, but the first one doesn't work properly.
```typescript
const [isClamped, setIsClamped] = useState(false)
const commentRef = useRef(null)
useEffect(() => {
if (commentRef.current?.scrollHeight! > commentRef.current?.clientHeight!) {
setIsClamped(true)
}
}, [])
```
```typescript
const [isClamped, setIsClamped] = useState(false)
const commentRef = useRef(null)
useEffect(() => {
setIsClamped(commentRef.current?.scrollHeight! > commentRef.current?.clientHeight!)
}, [])
```
Both strategies should work, right? The ref starts as null, which doesn't set `isClamped` to true, but then it renders, updates the ref and changes `isClamped` to true. (In the second
Except it doesn't, only the three latter columns get re-rendered for some reason. When checking the profiler, it shows that it re-rendered because of hook 3 (hasMounted):

and that Masonry's `columnCount` prop also changed.
What actually happens is this (logging the result of that condition):

Using a hand-made masonry component fixes this problem without any changes to the component with the `useEffect`, so it's something in this lib.
In fact I was wrong when I said that the ref started as null, because it's defined from the get-go (when using this hand-made component):

Contributor guide
Research direction
Start by reproducing the shown useEffect behavior with ResponsiveMasonry, then inspect how its hasMounted state and columnCount changes affect the first column. Compare the result with the hand-made masonry component described in the issue. Done means the first column receives the correct ref and rerenders consistently with the other columns.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, react, typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100