jackyef / react-isomorphic-data Goto Github PK

This would really help if we can define fetch policy globally instead if defining during each use of useData.

Most API's will follow common cached + network policy while there could be only exception 1/2 API's will be network only

Test-utils will contain things needed for consumer to test their app

https://codesandbox.io/post/codesandbox-ci-embeds

We've been looking at introducing react-isomorphic-data to Simorgh and have noticed that just implementing this library and not including any extra data fetches has nearly doubled the latency/response time of the application. Including 1 extra data fetch nearly triple's the response time when server side rendering.

Is this something you have observed before? or something you are aware of?

This is our application running against the latest (master) branch without the library.

This is the application with this library introduced, however with no extra data fetching.

And this is with 1 data fetch using the useData() hook

Since a lot of react-based libraries are also depending on this, I think this could be made a peerDep to avoid duplications

Hi, Love this idea behind this repo.

I tried out the ssr example code you have in the readme and I get this error from the try catch around the getTreeData method.

TypeError: Object(...) is not a function

We can refer to how https://github.com/zeit/swr implements this.

This will be really nice to have, but I think this should be implemented after other stuffs are done.

Ideally, implementing this should include a render-as-you-fetch functionality as well.

references:
https://twitter.com/dan_abramov/status/1191569529471549440
https://youtu.be/JDDxR1a15Yo?t=5210
https://reactjs.org/docs/concurrent-mode-suspense.html

We can make it so we import from /ssr directly for ssr related stuffs

import { renderToStringWithData } from 'react-isomorphic-data/ssr`

This should reduce the bundle size of the main package a little bit.

I get the following error in the console log when I run my server:

Error while trying to getDataFromTree TypeError: Object(...) is not a function
    at _callee$ (webpack:///./server/src/utils/serverUtils.js?:68:97)
    at tryCatch (/Users/username/codex/myprojects/bunch/current/node_modules/babel-polyfill/node_modules/regenerator-runtime/runtime.js:65:40)
    at Generator.invoke [as _invoke] (/Users/username/codex/myprojects/bunch/current/node_modules/babel-polyfill/node_modules/regenerator-runtime/runtime.js:303:22)
    at Generator.prototype.<computed> [as next] (/Users/username/codex/myprojects/bunch/current/node_modules/babel-polyfill/node_modules/regenerator-runtime/runtime.js:117:21)
    at asyncGeneratorStep (webpack:///./server/src/utils/serverUtils.js?:18:103)
    at _next (webpack:///./server/src/utils/serverUtils.js?:20:194)
    at eval (webpack:///./server/src/utils/serverUtils.js?:20:364)

I was following the example given here to https://react-isomorphic-data.netlify.app/docs/ssr/getdatafromtree implement in my project.

If I change my project to use this: https://react-isomorphic-data.netlify.app/docs/ssr/rendertostringwithdata it works perfectly fine.

My packages:-
"react": "16.13.1"
"react-dom": "16.13.1"
"react-helmet": "6.0.0"
"react-isomorphic-data": "0.16.0"
"express": "4.17.1"
"isomorphic-fetch": "2.2.1"
"react-redux": "7.2.0"
"redux": "4.0.5"
"redux-thunk": "2.3.0"

Since renderToStringWithData is working fine and I'm fine using it, but I thought I'll report just in case you would want to take a look and fix it at why getDataFromTree not working.

My implementation was something like this.

export const reactRender = async (req, res) => {
   const {routes, store} = res.locals
   const dataClient = createDataClient({
     initialCache: {},
     ssr: true,
     headers: {
        'cookie': req.header('cookie'),
        'User-Agent': req.header('User-Agent'),
        'X-Forwarded-For': req.header('X-Forwarded-For'),
        'X-Real-IP': req.header('X-Real-IP'),
        'Accept': req.header('Accept'),
        'Host': req.header('Host')
     }
  })

  const tree = (
    <DataProvider client={dataClient}>
      <Provider store={store}>
         <AppContext.Provider
            value={context}>
            <StaticRouter location={req.url}>
               {routes}
             </StaticRouter>
         </AppContext.Provider>
      </Provider>
    </DataProvider>
  )

  let html
  try {
     await getDataFromTree(tree, dataClient)
     html = renderToString(tree)
  } catch (err) {
     console.error('Error while trying to getDataFromTree', err)
  }

  Object.assign(res.locals, {
     cache: dataClient.cache,
     appHtml: html
  })
}

I call this function in my index.js in express server as follows:

await reactRender(req, res)
res.set('Content-Type', 'text/html')
res.status(200).end(lodashTpl(res.locals))

Let me know if you need any other information from my side. Thanks.

This can be useful during SSR so we can generate link rel="prefetch" tags, for resources that are not fetched during SSR. prefetch will automatically tries to fetch the resources when the browser is idle, and if it finishes, the resources will be ready in the browser cache already.

Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ

Currently waiting for siddharthkp/bundlesize#348 to be fixed,
then I will work on jackyef/bundlesize-gh-action#1 to be used in this repo.

Possible alternative: https://github.com/bundlewatch/bundlewatch

Things that we will need to ensure still works after migrating:

• Bootstrapping
• Linking
• Building
• Git Tags, Release Notes, and changelog generation

Since this library isn't exactly used by a lot of people, this might be tough to do.

What I am thinking right now is that we can:

1. Make sure we are satisfied with the overall API designs
2. Make sure we are confident enough that our tests have covered most cases
3. Have a release candidate ready, whatever version it might be
4. Spread on twitter? medium?

#48 (comment)

Currently, the cache is a very simple object with an absolute URL as key, and an object as the value of the key.

window.__cache= {
	"http://localhost:3000/some-rest-api/1": {"message":"/some-rest-api/1","randomNumber":79},
	"http://localhost:3000/some-rest-api/123": {"message":"/some-rest-api/123","randomNumber":47}
	"http://localhost:3000/some-rest-api/345": {"message":"/some-rest-api/123","randomNumber":23}
}

At a glance, we should be able to write this cache as:

window.__cache= {
  "http://localhost:3000": {
    "/some-rest-api": {
      "/1": {"message":"/some-rest-api/1","randomNumber":79},
      "/123": {"message":"/some-rest-api/123","randomNumber":47},
      "/345": {"message":"/some-rest-api/123","randomNumber":23}
    }
  }
}

or even:

window.__cache= {
  "http": {
	"localhost:3000": {
	  "some-rest-api": {
        "1": {"message":"/some-rest-api/1","randomNumber":79},
	    "123": {"message":"/some-rest-api/123","randomNumber":47},
	    "345": {"message":"/some-rest-api/123","randomNumber":23}
	  }
	}
  }
}

In larger objects, especially if many of the base path of the APIs are the same, this can save a lot size, which means smaller initial HTML document size.

User of the library should be able to define what they data is going to look like. Something like

interface MyData {
  foo: string;
  bar: number;
}

const { data, error, error } = useData<MyData>(url);

Add skip to dataOptions to be used to skip fetching when a certain case is met

Currently we are hardcoding the method to GET.

We can actually open this up to support all other methods for useLazyData. For useData we still only allow GET request. This can add more functionalities, such as POST-ing data on button click, etc.

Any example with the life cycle of a traditional component?

class Component extends React.Component {

  state = { data: [] };

  async componentDidMount(){
    const data = await useData(API);
    this.setState({ data });
  }

  render(){
     console.log('data', data)
  }
}

I have not tried

https://app.bundle-analyzer.com/

Since #8 might be long, maybe this can be used as an alternative, IF it will support rollup in the near future.

Context + hooks will cause many re-renders.

Consider using subscription model like redux did to improve on this situation.

facebook/react#15156

We can learn from redux journey https://blog.isquaredsoftware.com/2018/11/react-redux-history-implementation/
https://github.com/reduxjs/react-redux/blob/master/src/hooks/useSelector.js

Sebastian from facebook team also says that the new Context API is not meant to be used to propagate state: https://twitter.com/sebmarkbage/status/1219836431972978689

I am now thinking of either add a tip in the docs to let users memoize their expensive tree themselves, instead of doing this from the library itself, since React does not seem to provide a good way to do this at the moment.

This would prevent a data that is already in the cache to be fetched immediately again upon client side hydration.

Reference: https://www.apollographql.com/docs/react/performance/server-side-rendering/

To prevent regressions in the future, this will be nice to have so the library can be more stable.

Currently, if a request to a specific URL already has a response in cache, it will always use the one in cache. Basically, the behavior now is like cache-first in react-apollo.

The library should be able to handle more policies such as cache-and-network and network-only. This will also have some effect on how fetching data during SSR works.