我正在将现有的应用程序移植到Flux,并且对一个主题有些困惑。假设我有几个API端点,它们返回两级或三级嵌套对象。
例如,GET /articles
可能返回架构的JSON响应
articles: article*
article: {
author: user,
likers: user*
primary_collection: collection?
collections: collection*
}
collection: {
curator: user
}
如您所见,有各种各样的用户处于不同的嵌套级别:
articles[i].author
articles[i].likers[i]
articles[i].primaryCollection.curator
articles[i].collections[i].curator
如果我想UserStore
在获取文章时随时使用新数据进行更新,则必须编写一个怪异的方法来检查文章API响应上的所有嵌套实体。而且,将存在很多重复,因为还有其他API端点具有不同的架构,有时文章嵌入在用户内部(例如GET /user/published
)。
Flux商店是否有更干净的方法 从所有API响应中提取嵌套实体?
Jing
Chen
(Flux的创建者和传播者之一)建议的一种方法是在API响应到达商店之前对其进行展平。我写了一个小库,它就是这样做的:
[{
id: 1,
title: 'Some Article',
author: {
id: 1,
name: 'Dan'
}
}, {
id: 2,
title: 'Other Article',
author: {
id: 1,
name: 'Dan'
}
}]
至
{
result: [1, 2],
entities: {
articles: {
1: {
id: 1,
title: 'Some Article',
author: 1
},
2: {
id: 2,
title: 'Other Article',
author: 1
}
},
users: {
1: {
id: 1,
name: 'Dan'
}
}
}
}
(请注意,没有重复且结构平坦。)
Normalizr 可让您:
要使用它,您需要定义您的实体和嵌套规则,并使用它们来转换JSON:
var normalizr = require('normalizr'),
normalize = normalizr.normalize,
Schema = normalizr.Schema,
arrayOf = normalizr.arrayOf;
// First, define a schema:
var article = new Schema('articles'),
user = new Schema('users'),
collection = new Schema('collections');
// Define nesting rules:
article.define({
author: user,
collections: arrayOf(collection)
});
collection.define({
curator: user
});
// Usage:
// Normalize articles
var articlesJSON = getArticleArray(),
normalized = normalize(articlesJSON, arrayOf(article));
// Normalize users
var usersJSON = getUsersArray(),
normalized = normalize(usersJSON, arrayOf(user));
// Normalize single article
var articleJSON = getArticle(),
normalized = normalize(articleJSON, article);
这使您可以在将任何XHR响应传递给Flux Dispatcher之前对其进行标准化。商店只需要从相应的字典进行更新即可:
// UserStore
UserStore.dispatchToken = AppDispatcher.register(function (payload) {
var action = payload.action;
switch (action.type) {
// you can add any normalized API here since that contains users:
case ActionTypes.RECEIVE_ARTICLES:
case ActionTypes.RECEIVE_USERS:
// Users will always be gathered in action.entities.users
mergeInto(_users, action.entities.users);
UserStore.emitChange();
break;
}
});
// ArticleStore
AppDispatcher.register(function (payload) {
var action = payload.action;
switch (action.type) {
// you can add any normalized API here since that contains articles:
case ActionTypes.RECEIVE_ARTICLES:
// Wait for UserStore to digest users
AppDispatcher.waitFor([UserStore.dispatchToken]);
// Articles will always be gathered in action.entities.articles
mergeInto(_articles, action.entities.articles);
ArticleStore.emitChange();
break;
}
});
在我们的spring boot应用程序中,我们出于某种目的调用外部API,它将返回大约20mb的JSON数据作为响应。收到响应后,使用ObjectMapper将响应映射到POJO。 我们正在使用RestTemboard调用API并接收响应。 在Spring启动应用程序中处理大型响应数据而不会出现内存问题的最佳实践是什么? 谢谢
问题内容: 我一直在从事一个更像框架的项目,并且可以安装几个应用程序/模块。像基本的应用商店或google.play商店一样看到它。这是一个Intranet应用程序,所有模块都可以添加到您的用户帐户中。 该框架已经在开发中,但是我现在正在围绕应用程序/模块的想法。(链接到开发中的概念证明,可以在这里找到) 一个应用程序应该是独立的,并且不能突然包含框架中的脚本,这可以通过在单独的模块中进行结构化来
问题内容: 我正在创建具有flux体系结构的react.js应用程序,并且试图弄清楚应该何时何地从服务器请求数据。有这个例子吗?(不是TODO应用!) 问题答案: 我强烈支持将异步写入操作放在动作创建者中,而将异步读取操作放在商店中。目标是将商店状态修改代码保留在完全同步的动作处理程序中;这使他们易于推理,并且易于进行单元测试。为了防止对同一端点的多个同时请求(例如,重复读取),我将把实际的请求处
问题内容: 我正在编写一个应用程序并导入一些包。该软件包具有目录,其中又包含package 。我也想直接在我的应用程序中使用该软件包。 因此,我决定使用包管理器。这两种下载和进入目录,但保持里面。因此,当我构建自己的应用程序时,它会使用两个不同的C版本(也使用)来构建。 如何避免呢? 1)要么,有可以处理该问题的软件包管理器?似乎有其论点,但它不尊重这些软件包的版本。 2)或者,如何正确处理嵌套目
在使用空手道框架进行API测试时,我在验证嵌套JSON响应时遇到了一些问题。 JSON响应: null def feed_cycle={item_type:'#string',title:'#string'} def feed_college_dept_branch={branch:'#string'} def feed_college={item_type:'#string',dept:'[]f