red-armor / xswr

:innocent: A data fetching solution for React Hooks and Imperative Ajax request

English | 简体中文

xswr

A data fetching solution for React Hooks and Imperative Ajax request

Introduction

xswr is inspired by swr and documentation HTTP RFC 5861 mentioned in its readme file. In general, comparing with swr, xswr has following features

1. Scenario, applicable for React Hooks and Promise-base Ajax request
2. Isolated Configuration Context, fetcher is identified by key param and shared by items with same key, config is isolated from each other.
3. Re-render control, In React Hooks, it is configurable to control whether re-render component or not caused by data change.
4. Easy to use, In Promise-based Ajax chain request, retry and pooling could be performed automatically.

Installation

With npm

npm install xswr

With yarn

yarn add xswr

How does xswr works

Usage

1. useXS - React Hooks solution
2. xs - Promise-based Ajax solution

xswr's Issues

update fetcher dynamically or not

Why it needs to consider whether update fetcher dynamically or not..

Firstly, has a look at the basic usage of xswr

xs(path, customizedFetcher, options)

path is used as an unique identifier to shared fetch pipe. According to data fetch optimization strategy , if path value is equal, they will be considered as the same request.

However, maybe there is a situation, You may think whether fetcher should be updated dynamically.

xs('init', () => axios.post('/user', {
  firstName: 'Fred',
  lastName: 'Flintstone'
})).then(res1 => {})

xs('init', () => axios.post('/user', {
  firstName: 'Charlie',
  lastName: 'Flintstone'
})).then(res2 => {})

res1 and res2 will be resolved with same value even if firstName is not the same in request body...

So how to fix this issue..

request should be token into account when creating path

const body1 = {
  firstName: 'Fred',
  lastName: 'Flintstone'
}
const p1 = `init_${JSON.stringify(body1)}`
xs(p1, () => axios.post('/user', body1)).then(res1 => {})

const body2 = {
  firstName: 'Charlie',
  lastName: 'Flintstone'
}
const p2 = `init_${JSON.stringify(body2)}`
xs(p2, () => axios.post('/user', body2)).then(res2 => {})

This solution will lost the cache benefit from xswr, because each request will a new Fetcher, in-memory cache data will be a new empty object..

So, you will consider whether it will be better update an existing fetcher.

updating an existing fetcher

In order to support this solution, there need much source code change.

1. Add a update method to fetcher
2. In update method, fetch, fetchArgs and finalized should be reset...

These two steps looks cover this issue. Now look the following example...

xs( "/api/user", url => service(url), {forceValidate: true}).then(r1 =>
  xs( "/api/user", url => service("/api/update"), { forceValidate: true }).then(r2 => {
    r1Counter++
    if (r1Counter === 1) {} // r2 should be { name: 'liu' }
    if (r1Counter === 2) {} // r2 should be { name: 'updated' }

    xs( "/api/user", url => service(url), {forceValidate: true}).then(r3 => {
      r2Counter++

      if (r2Counter === 1) {} // r3 should be { name: 'liu' }
      if (r2Counter === 2) {} // r3 should be { name: 'updated' }
      if (r2Counter === 3) {} // r3 should be { name: 'liu' }. Actually, it is { name: 'updated' }
    })
  })
)

Re-think the reason why r3's value is {name: 'update'}..

Because, even thought fetch, fetchArgs and finalized have been reseted. subscribers is still be shared. when the old request resolved, it will execute all the subscribers.

Maybe you will think, so we just reset subscribers... But in xswr's design philosophy, fetcher is shared between application... because you do not know whether current path fetcher is used by others', reset subscribers may cause other application lost its subscription...

axios compatible write style support