React Admin-如何使用abc / def之类的嵌套路径调用dataProvider

Question

React-admin的Resource组件将nameprop值映射到一个端点。

例如从访问数据。http://example.com/abc，您的Resource组件如下所示： <Resource name='abc'/>

我要访问什么资源http://example.com/abc/def？这<Resource name='abc/def'/>甚至不调用该dataProvider函数。

我不想以如下丑陋的解决方案结束：

// App.js
<Resource name='def'/>

---

// dataProvider.js
if (resource==='def') {
url = 'abc/def'
}

资源名称是否必须始终没有/？有骇客吗？

Answer 1

我正在开发一个项目，最终我们编写了自己的 dataProvider，因为我们的 api 并不是严格意义上的 RESTful。

这有点让人难以理解，但一旦你弄清楚了工作流程，它也不算太糟糕。

调用 dataProvider 时基本上会发生三件事

1. dataProvider 使用参数调用convertDataProviderRequestToHTTP，它返回一个 url 和用于发送 fetch/api 调用（构建请求）的选项
2. 发送 fetch 请求/api 调用（发送请求）
3. dataProvider 返回调用convertHTTPResponseToDataProvider 的结果，该函数将响应转换为对接收它的资源有用的内容（处理来自请求的响应）

这是react-admin文档相关部分的链接 https://marmelab.com/react-admin/DataProviders.html#writing-your-own-data-provider

我们的解决方案使用 switch 语句，其 case 是类型，然后每个 case 都有处理不同资源的逻辑。

我不确定这是否是预期的实现，但我们最终得到了这样的结果：

// import all the things

// set your api path prefix

const convertDataProviderRequestToHTTP = (type, resource, params) => {
     //switch statement with one case for each action type
     // and some logic where necessary for different resources ie. 
    switch(type){
        case "GET_ONE":{
            // if statements to handle resources with goofy endpoints
            if(resource === 'abc/def'){
                const url = `${API_PREFIX}/abc/def`;
                const options = {
                    // set the specific options that you need for a 
                    // each particular resource
                }
            }

            // handles resources with normal restful endpoints
            const url = `${API_PREFIX}/${RESOURCE}`;
            const options = {
                // this part depends on how you're doing your fetching
                // might need to include the particular rest verb
                // and any other settings
            }
        }

    }
    return {
        url,
        options
    }

}

const convertHTTPResponseToDataProvider = (response, type, resource, params){
    // another switch statement that converts the response that you get
    // from your api to something that's useful to your Resource
    switch(type){
        case 'GET_ONE':{
            if(resource === 'abc/def'){
                // convert response into something useful and return it
                return{
                      data: convertedResponse
                }
            }
        }
    }
}

export default (type, resource, params) => {

    // this comes from react-admin, you could use plain old fetch or
    // your favorite fetch library like axios instead
    const { fetchJson } = fetchUtils;

    // part 1, using the stuff that was sent in the dataProvider 
    // call to generate what you need to sending your fetch
    const { url, options } = convertDataProviderRequestToHTTP(
        type,
        resource,
        params
    );

    // add logic for grabbing your tokens and adding headers to options here
    options.headers.set('headerkey', 'headervalue');

    // part 2 sending the fetch request
    return fetchJson(url, options).then(response =>
        // part 3, converting the response and returning it
        convertHTTPResponseToDataProvider(response, type, resource, params)
    );
};

随着应用程序的发展，我们最终将其分成单独的文件，以便更容易阅读，但到目前为止，它似乎对我们来说还不错。

我必须安装 redux 浏览器工具并插入大量日志记录语句来逐步执行它并更好地了解发生了什么以及何时发生。在获得第一个操作类型/资源组合后，它有点点击并添加到它，从那时起就很容易弄清楚。