I've devided my pages folder on 2 sections:
mobile
desktop
And I do some rewrote on the server
import { NextRequest, NextResponse } from 'next/server';
const isMobile = (userAgent: string) =>
/iPhone|iPad|iPod|Android/i.test(userAgent);
export function middleware(req: NextRequest) {
const userAgent = req.headers.get('user-agent');
const { pathname, origin } = req.nextUrl;
if (userAgent && !pathname.includes('favicon.ico')) {
if (isMobile(userAgent)) {
return NextResponse.rewrite(`${origin}/mobile${pathname}`);
} else {
return NextResponse.rewrite(`${origin}/desktop${pathname}`);
}
}
}
It is great , I hadnle 2 sizes - more 1280 and lower , and on those 2 I have some breakpoints. But what is user for example switch from <1280 to >1280, is there any way to detect it on client ( there is ) and rewrite it same way as on _middleware ?
One way to do this might be to use an observer that reports changes at an app level ( this kind of avoids the isDesktop like logic) - it unfortunately is doing isDesktop like logic but works more at a observer level.
i.e
// Modified from package example.
import { Observe } from '#envato/react-breakpoints';
const exampleBreakpoints = {
widths: {
0: 'mobile',
769: 'tablet',
1280: 'desktop',
}
};
export const ExampleComponent = () => (
<Observe breakpoints={exampleBreakpoints}>
{({ observedElementProps, widthMatch = 'ssr' }) => (
<div {...observedElementProps}>
<div className={widthMatch}>
<YourComponent />
</div>
)}
</Observe>
);
https://github.com/envato/react-breakpoints
The interesting thing about this package is on the server, you will get undefined, see https://github.com/envato/react-breakpoints/blob/main/docs/server-side-rendering.md
Instead of doing user agent matching, you can reflect where the changes are happening, this means you can do SSR accordingly like you were doing.
I see the flow happening like below:
User loads a page on Desktop - SSR gets undefined from so renders a Desktop page
User resizes, ResizeObserverProvider will trigger and since its a provider, it will cascade the props to children who can use it.
This is one of the many ways to do it but it involves client side calculations.
Related
API:
import {
createApi,
fetchBaseQuery,
} from '#reduxjs/toolkit/query/react'
import { RootState } from 'store'
export interface FeedType {
id: string
title: string
imgUrl: string
}
export const feedsApi = createApi({
reducerPath: 'feeds',
tagTypes: ['Feeds'],
baseQuery: fetchBaseQuery({
baseUrl: 'http://localhost:5000',
}),
endpoints: (build) => ({
getFeedsMore: build.query<FeedType[], void>({
async queryFn(arg, queryApi, extraOptions, baseQuery) {
const state = queryApi.getState() as RootState
const selector = feedsApi.endpoints.getFeedsMore.select() as (
state: any
) => any
const result = selector(state) as { data: FeedType[] } | undefined
const oldData = (result?.data ?? []) as FeedType[]
const { data } = await baseQuery({
url: 'feeds?_page=' + Math.round(oldData.length / 10 + 1),
})
return { data: [...oldData, ...(data as FeedType[])] }
},
}),
}),
})
export const {
useGetFeedsMoreQuery,
} = feedsApi
Component:
import FeedItem from 'components/FeedItem'
import React from 'react'
import Masonry from 'react-masonry-css'
import { useGetFeedsMoreQuery } from 'services/feeds'
interface FeedsMorePageProps {}
const FeedsMorePage: React.FunctionComponent<FeedsMorePageProps> = () => {
const { isLoading, data: feeds, refetch } = useGetFeedsMoreQuery()
return (
<>
{isLoading ? (
'loading'
) : (
<>
<Masonry
breakpointCols={{
default: 3,
1100: 2,
700: 1,
}}
className="my-masonry-grid"
columnClassName="my-masonry-grid_column"
>
{feeds &&
feeds.map((feed) => <FeedItem key={feed.id} feed={feed} />)}
</Masonry>
<button className="btn btn-info" onClick={() => refetch()}>
Load More...
</button>
</>
)}
</>
)
}
export default FeedsMorePage
I know it is totally a mess, this is the only clumsy way I could make it run.
What is the best practice to this scenario?
It is common to use dispatch and getState in a Thunk-Action, but the most confusing part to me is in queryFn I have getState and endpoint.select methods, but I do not know how to type them in typescript.
feedsApi.endpoints.getFeedsMore.select()(state as RootState)
// this gives me a super long type incompatible complain
I can not use useSelector hook here neither, util I made out this ugly way...
Generally, no, that's not what you should do. Building one cache entry that large will mean that eventually you will run out of memory. It can never be collected, so it will just keep growing. But if the user scrolled down to item 9500, you really don't need to keep item 1000 in memory any more.
Especially when you are displaying all those elements in your DOM.
And if you are not displaying all those elements in the DOM, there is also no need to have all of them in the cache.
So, assume you use some kind of virtualization library like react-virtual.
That means you know you have theoretically 10000 items to display, but you only render what is in view and a bit to the front and a bit to the back.
Then keep your endpoint also to a window.
Have your endpoint fetch "parts", so if the user is looking at item 9500, you maybe have items 9500-9550 on the screen and you want to keep some more fetched to quickly display them - one page to the front and one to the back.
So now you use your query hook three times in your component: the current "page" (9500-9550), the last "page" (9450-9500) and the next "page" (9550-9600).
That way, stuff not in view can at some point be cache-collected if it was not in view long enough.
Another way of doing that would be to just render "page" components from a parent component - and each of those "page" components would request their "window of data", while a "get more" button would add another element to the "pages" array in the parent component.
But either way: you would not stitch all of that together in the cache, but keep it as separate cache entries - and then decide to access which of those to access in your component and how to stitch them together.
Generally, I can recommend to read up on this GitHub discussion where multiple people share their approaches to the topic.
I am building an online course website.
When the user watches a lesson in full-screen mode, I want to remember that, so as to use full-screen mode when I mount react-player with the next lesson. I hoped there would be an onFullscreenMode callback, but the documentation does not list anything of the kind. How can I achieve this?
Edit 1: Based on the reply of #onkarruikar, I tried using screenfull. First, I was surprised that it was not installed although real-player was supposed to use it to enter full-screen mode. After installing the package and importing it, I get the compilation error:
.../node_modules/screenfull/index.js 11:44
Module parse failed: Unexpected token (11:44)
File was processed with these loaders:
.../node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.
|
| for (const methodList of methodMap) {
> const exitFullscreenMethod = methodList?.[1];
|
| if (exitFullscreenMethod in document) {
Edit 2: I also don't get it why the demo uses a custom button for switching to full-screen mode, whereas I see a button () on the player itself:
The player doesn't have fullscreen inbuilt. It uses screenfull to go full-screen. As per their demo https://cookpete.com/react-player/ full-screen is handled externally by the component users.
You can use following screenfull features directly on your website:
screenfull.isFullscreen //<-- is the browser in fullscreen
screenfull.isEnabled //<-- is the facility available to use
screenfull.request(element);
screenfull.toggle(element);
etc.
Or you can use standard web apis like:
if(document.fullscreenElement) { //<-- is the browser in fullscreen
...
}
document.fullscreenEnabled //<-- is the facility available to use
Document.fullscreenElement / ShadowRoot.fullscreenElement
The fullscreenElement property tells you the Element that's currently being displayed in full-screen mode on the DOM (or shadow DOM). If this is null, the document (or shadow DOM) is not in full-screen mode.
ref
These apis should work even if you go fullscreen using controls inside player.
Here is a demo website using react: https://gizcx.csb.app/
Corresponding codesandbox code
Also, if you are not playing videos one by one then you can pass full course playlist to the player at once:
<ReactPlayer
url={[
'https://www.youtube.com/watch?v=oUFJJNQGwhk',
'https://www.youtube.com/watch?v=jNgP6d9HraI'
]}
/>
For the benefit of others, this is how it is achieved:
import { findDOMNode } from 'react-dom'
import { toast } from 'react-toastify';
const PlayerComponent = () => {
const [fullscreenMode, setFullscreenMode] = useState(false)
let player = null;
const ref = (p) => {player = p;}
const onStart = () => {
if (fullscreenMode)
findDOMNode(player).requestFullscreen().catch(
(err) =>
{toast.error("Could not activate full-screen mode :(")}
);
}
const onEnded = () => {
setFullscreenMode(document.fullscreenElement !== null);
}
return (
<ReactPlayer
ref={ref}
url="whatever url"
onStart={onStart}
onEnded={onEnded} />);
);
}
I'm pretty new with Next.js and do not fully understand the cache functioning.
Given the following simplified example:
An index page that renders components Test1 or Test2, depending whether the current minute is even or odd:
import { Test2 } from '#src/components/test2'
import React from 'react'
const conditionallyChooseComponent = () => {
const d = new Date()
if (d.getMinutes() % 2 === 0) return <Test1 />
else return <Test2 />
}
export default function Home() {
return <div>{conditionallyChooseComponent()}</div>
}
And having the following components. Test1:
export const Test1 = () => {
const d = new Date()
return (
<div className={`${utilStyles.redContainer}`}>
<h1>It's {d.toISOString()} and I'm Test1 component. My background should be red</h1>
</div>
)
}
And Test2:
export const Test2 = () => {
const d = new Date()
return (
<div className={`${utilStyles.blueContainer}`}>
<h1>It's {d.toISOString()} and I'm Test2 component. My background should be blue</h1>
</div>
)
}
And this CSS:
.redContainer {
background-color: red;
}
.blueContainer {
background-color: blue;
}
The background color is being cached when the code is executed by building and serving from the transpiled code. When running with yarn dev it is working just fine.
Here is the unexpected result:
Screenshot with Test1 component being rendered with blue background
PS: I made this work with the workaround of using the getInitialProps to prevent Next.js from caching anything in that page but, for my real use case that option is not valid because I need the render condition to be calculated in the client side since it will depend on the local date of the browser.
Next will automatically cache all static pages that doesn't depends on external data, maybe you can implement useEffect to update your date variable or use a simple state, so it should work the way you expect
https://nextjs.org/docs/basic-features/pages#static-generation-without-data
To make that works, you will need to add some client-side code (via useEffect), so the React component updates every minute (or so). Funny enough, this is not as simple as it sounds, and even Dan Abramov has published a long post explaining why things such as setInterval may not work intuitively with React (specifically, with React Hooks).
Assuming you use the custom hook Dan explains in the article above, this should work:
export default function Home() {
const [date, setDate] = useState(new Date());
useInterval(() => {
// this will update the component's date every second
setDate(new Date());
}, 1000);
return <div>{date.getMinutes() % 2 === 0 ? <p>Test 1</p> : <p>Test 2</p>}</div>;
}
Observe that your code example only executes the conditionallyChooseComponent once, just when Next is trying to server-side rendering your page.
I need to conditionally render components based on screen size.
I use nextjs and getInitialProps for data fetching, the page is server-side rendered. I want to detect device screen size on the client-side, so I implement a customized hook to do it.
useWindowSize.js
import { useEffect, useState } from 'react';
export default function useWindowSize() {
const [windowSize, setWindowSize] = useState({
width: typeof window === 'undefined' ? 1200 : window.innerWidth, // default width 1200
});
useEffect(() => {
// Handler to call on window resize
function handleResize() {
// Set window width/height to state
setWindowSize({
width: window.innerWidth,
//height: window.innerHeight,
});
}
// Add event listener
window.addEventListener('resize', handleResize);
// Call handler right away so state gets updated with initial window size
handleResize();
// Remove event listener on cleanup
return () => window.removeEventListener('resize', handleResize);
}, []); // Empty array ensures that effect is only run on mount
return windowSize.width <= 600;
}
then I use this hook to detect window size and conditional render components
export default function IndexPage() {
const isMobile = useWindowSize();
if (typeof window !== "undefined") {
// if you are running it on codesanbox, I don't know why log is not printed
console.log("client side re-render");
}
return (
<div>
{isMobile ? (
<div
style={{
color: "red",
fontSize: 40
}}
>
mobile
</div>
) : (
<div
style={{
color: "blue",
fontSize: 20
}}
>
desktop
</div>
)}
</div>
);
}
IndexPage.getInitialProps = () => {
return {
a: 1
};
};
when I load the page on mobile browser, you will see
text mobile is applied wrong CSS style. video demo: https://share.getcloudapp.com/nOuk08L0
how to reproduce:
https://codesandbox.io/s/thirsty-khayyam-npqpt
Can someone please help me out. Thank you in advance!
This is an issue that is related to how React patch up DOM from SSR. When there is a mismatch between client-side and server-side rendering, React will only patch/sync the text context for the node. The DOM attribute will not be automatically updated. In your case, the SSR result has the desktop style because there is no window object, and client side has the mobile result. After the mismatch, React update the text node from 'desktop' to mobile but not the style attributes.
In my opinion, you can use two different approaches. You can use Media Query to style your component based on the screen width instead of the hook. If you are doing SSR, not SSG, you can use user agent req.headers["user-agent"] to detect the device your device is being viewed on.
For the first approach, you might need to render more DOM node you might need to. For the second approach, you won't be able to know the actual viewport size, which can cause visual issue. You might be able to combine both approach to produce a good viewing experience for your user.
Reference
https://github.com/facebook/react/issues/11128#issuecomment-334882514
Thanks for #Andrew Zheng's detailed explanation! Today I learned.
I know that I can style the layout by using pure CSS media query, but my use case needs a variable like isMobile to
if (isMobile) {
doSomethingOnlyOnMobileWeb();
} else {
doSomethingOnlyForDesktopWeb();
}
So I combined two approaches you provided, and modify my hook this way:
export default function useWindowSize(userAgent) {
let isMobile = Boolean(
userAgent &&
userAgent.match(
/Android|BlackBerry|iPhone|iPod|Opera Mini|IEMobile|WPDesktop/i
)
);
const [windowSize, setWindowSize] = useState({
width: isServer
? isMobile
? BREAKPOINT_SMALL
: BREAKPOINT_LARGE
: window.innerWidth,
});
useEffect(() => {
// Handler to call on window resize
function handleResize() {
// Set window width/height to state
setWindowSize({
width: window.innerWidth,
//height: window.innerHeight,
});
}
// Add event listener
window.addEventListener('resize', handleResize);
// Call handler right away so state gets updated with initial window size
handleResize();
// Remove event listener on cleanup
return () => window.removeEventListener('resize', handleResize);
}, []); // Empty array ensures that effect is only run on mount
return windowSize.width <= BREAKPOINT_SMALL;
}
diff: passing user-agent string to useWindowSize for server-side detection and use window.innerWidth for client-side detection. There won't be a mismatch between server and client.
I have created a bare-bones Meteor app, using React. It uses the three files shown below (and no others) in a folder called client. In the Console, the App prints out:
withTracker
rendering
withTracker
rendering
props {} {}
state null null
In other words, the App component is rendered twice. The last two lines of output indicate that neither this.props nor this.state changed between renders.
index.html
<body>
<div id="react-target"></div>
</body>
main.jsx
import React from 'react'
import { render } from 'react-dom'
import App from './App.jsx'
Meteor.startup(() => {
render(<App/>, document.getElementById('react-target'));
})
App.jsx
import React from 'react'
import { withTracker } from 'meteor/react-meteor-data'
class App extends React.Component {
render() {
console.log("rendering")
return "Rendered"
}
componentDidUpdate(prevProps, prevState) {
console.log("props", prevProps, this.props)
console.log("state", prevState, this.state)
}
}
export default withTracker(() => {
console.log("withTracker")
})(App)
If I change App.jsx to the following (removing the withTracker wrapper), then the App prints only rendering to the Console, and it only does this once.
import React from 'react'
import { withTracker } from 'meteor/react-meteor-data'
export default class App extends React.Component {
render() {
console.log("rendering")
return "Rendered"
}
componentDidUpdate(prevProps, prevState) {
console.log(prevProps, this.props)
console.log(prevState, this.state)
}
}
What is withTracker doing that triggers this second render? Since I cannot prevent it from occurring, can I be sure that any component that uses withTracker will always render twice?
Context: In my real project, I use withTracker to read data from a MongoDB collection, but I want my component to reveal that data only after a props change triggers the component to rerender. I thought that it would be enough to set a flag after the first render, but it seems that I need to do something more complex.
This a "feature", and it's not restricted to Meteor. It's a feature of asynchronous javascript. Data coming from the database arrives after a delay, no matter how quick your server is.
Your page will render immediately, and then again when the data arrives. Your code needs to allow for that.
One way to achieve this is to use an intermediate component (which can display "Loading" until the data arrives). Let's say that you have a component called List, which is going to display your data from a mongo collection called MyThings
const Loading = (props) => {
if (props.loading) return <div>Loading...</div>
return <List {...props}></List>
}
export default withTracker((props) => {
const subsHandle = Meteor.subscribe('all.myThings')
return {
items: MyThings.find({}).fetch(),
loading: !subsHandle.ready(),
}
})(Loading)
It also means that your List component will only ever be rendered with data, so it can use the props for the initial state, and you can set the PropTypes to be isRequired
I hope that helps
Unsure if you're running into the same error I discovered, or if this is just standard React behavior that you're coming into here as suggested by other answers, but:
When running an older (0.2.x) version of react-meteor-data on the 2.0 Meteor, I was seeing two sets of distinct renders, one of which was missing crucial props and causing issues with server publications due to the missing data. Consider the following:
// ./main.js
const withSomethingCount = (C) => (props) => <C { ...props } count={ ... } />
const withPagination = (C) => (props) => <C { ...props } pagination={ ... } />
const withSomething = withTracker((props) => {
console.log('withSomething:', props);
});
// Assume we're rending a "Hello, World" component here.
export const SomeComponent = withSomethingCount(withPagination(withSomething(...)));
// Console
withSomething: { count: 0 }
withSomething: { count: 0, pagination: { ... } }
withSomething: { count: 0 }
withSomething: { count: 0, pagination: { ... } }
For whatever reason, I was seeing not only N render calls but I was seeing N render calls that were missing properties in a duplicate manner. For those reading this and wonder, there was one and only one use of the component, one and only one use of the withTracker HoC, the parent HoCs had no logic that would cause conditional passing of props.
Unfortunately, I have not discovered a root-cause of the bug. However, creating a fresh Meteor application and moving the code over was the only solution which removed the bug. An in-place update of the Meteor application (2.0 to 2.1) and dependencies DID NOT solve the issue... however a fresh installation and running a git mv client imports server did solve my problems.
I've regrettably had to chalk this up to some form of drift due to subsequent Meteor updates over the two years of development.