Open kettanaito opened 4 years ago
breakpointName
even useful? What can be the usage example?It's about never you have interest in a matched breakpoint name without deriving something from it. To do the latter there is a callback function (hook argument), which replaces the need to return the breakpoint name. I'd probably make the useBreakpoint
hook return the data only.
i also find this interesting, i did came up with 2 hooks on my lib:
useCurrentBreakpoint
that returns a string with the key of the current breakpointuseBreakpoints
that returns an array containing all the visible breakpoints keysI absolutely love the useCurrentBreakpoint
hook! I think it would be a nice replacement of the useBreakpointChange
, which exposes you a callback with a currently matched breakpoint name. It'd be a much more versatile pattern to return a breakpoint name instead, and let the end developer decide what to do with it:
import { useBreakpointChange } from 'atomic-layout'
const Usage = () => {
// Instead of inline side-effect
useBreakpointChange((currentBreakpointName) => {...})
// Prefer getting the active breakpoint name and doing whatever is needed with it
const breakpointName = useCurrentBreakpoint()
useEffect(() => {...}, [breakpointName])
}
@vitordino, could you please share a use case for the useBreakpoints
hook you've mentioned?
I think I understood why multiplicity is relevant when matching breakpoints. I've addressed it in the pull request attached to this issue. Basically, it's possible for multiple breakpoints to match the same state of the viewport.
The call signature I'm suggesting in the pull request is:
import React, { useEffect } from 'react'
import { useCurrentBreakpoints } from 'atomic-layout'
const Usage = () => {
const breakpoints = useCurrentBreakpoints()
useEffect(() => {
if (breakpoints.includes('sm')) {
doAction()
}
}, [breakpoints])
return null
}
I can see such hooks being used with some sort of comparison util. For example
isInRage('sm', { to: 'md' })
. I'm not sure there's a lot of value in such standalone usage, though.
But then, once such utility is introduced, I see no difference between it and useResponsiveQuery
, which allows you to check if the current viewport matches the query range.
I mainly wonder what is the benefit of the useCurrentBreakpoint
hook compared to:
import { useResponsiveQuery } from 'atomic-layout'
const Usage = () => {
// Target a single breakpoint
const isLargeScreen = useResponsiveQuery({ for: 'lg' })
// Or a breakpoint range
const isBiggerThanMedium = useResponsiveQuery({ from: 'md' })
}
Effectively one reaches to a hook like useCurrentBreakpoint
to find out what the current breakpoint is, which implies that it matches against the current viewport. I believe that match is the exact useful information, not the breakpoint name per say.
It would be nice to have a usage example of useCurrentBreakpoint
to assess if it's a useful hook at the first place.
yep, you caught one idea of using an array on useBreakpoints
.. i think it’s just a different way to express it, and maybe use it..
i’m not agains the from/to
(or below/above
) approaches, i even think that probably it’s more powerful too, but i believe both API’s can live simultaneously..
just some other ways to let users of the lib explore the api (some will prefer only using one of it, but maybe there are best uses for both) 🤷
@vitordino, you have a point. While reading your reply I've also realized that useCurrentBreakpoints
has a slightly different behavior than useResponsiveQuery
. I'll elaborate below.
useResponsiveQuery
Designed to determine a viewport match against a breakpoint, or a range of breakpoints. More precisely, a range of breakpoints of the same nature (i.e. dimensional, orientational, or pixel density breakpoints). With this hook you cannot, say, get the match in case you would like to know if it's a medium breakpoint or a retina display. You would have to use such hook twice:
const isMedium = useResponsiveQuery({ for: 'md' })
const isRetina = useResponsiveQuery({ for: 'retina' })
Usage example above assumes you have got two breakpoints defined:
md
andretina
, usingLayout.configure({})
.
useCurrentBreakpoints
This hook, on the other hand, returns the list of all breakpoints that match the current viewport. Breakpoints in the list may be of a different nature.
Taking the same md/retina example above, you could get the match information in a single useCurrentBreakpoints
hook call:
const breakpoints = useCurrentBreakpoints()
if (breakpoints.includes('md') && breakpoints.includes('retina')) {
// do something
}
This does not necessarily mean that this is a more performant method, as
useResponsiveQuery()
establishes amatchMedia()
only against a breakpoint or a range you've provided, whileuseCurrentBreakpoint
checks if any declaredLayout.options.breakpoints
math the current viewport.
I believe that both hook have a place to be. I'd love for the users to give them a try and see what are the use cases for both. I've prepared the implementation for useCurrentBreakpoints
in #318, and will continue on it, since my original question was answered.
What:
I suggest to add the following React hook:
Why:
It should replace current
useBreakpointChange
hook with both:useBreakpointChange
.useBreakpoint
will be called on initial render, whenuseBreakpointChange
is not.Main motivation is that it's currently lengthy to know which breakpoint is met. It requires to have
useState
updating its value onuseBreakpointChange
callback. With the suggested hook added it can be written in a single hook declaration.Usage example:
Getting a breakpoint name
Reacting to breakpoint change
How:
useBreakpointChange
useBreakpoint