在编写redux-thunk函数时,称为thunks,有很多样板可以很容易地被抽象掉.例如,在我们的大多数异步API调用中,我们正在执行以下操作,没有任何副作用:
export const LOGIN_REQUEST = 'my-app/auth/LOGIN_REQUEST';
export const LOGIN_RECIEVE = 'my-app/auth/LOGIN_RECIEVE';
export const LOGIN_FAILURE = 'my-app/auth/LOGIN_FAILURE';
// ... reducer code here
export function login(loginHandle, password) {
return (dispatch, getState, api) => {
dispatch({ type: LOGIN_REQUEST });
api.post('/auth/login', { loginHandle, password }).then(
response => dispatch({ type: LOGIN_RECIEVE, response }),
error => dispatch({ type: LOGIN_FAILURE, error })
);
};
}
Run Code Online (Sandbox Code Playgroud)
简单!虽然因为这涵盖了我们至少70%的请求,但我确信有一种优雅的方法可以将上述代码抽象为类似的东西(伪代码):
export function login(loginHandle, password) {
return (dispatch, getState, api) => api('POST', LOGIN_REQUEST, '/auth/login', { loginHandle, password }); …Run Code Online (Sandbox Code Playgroud) 是否可以thunk在特定路由上调用异步redux操作,并且在响应成功或失败之前不执行转换?
用例
我们需要从服务器加载数据并使用初始值填充表单.在从服务器获取数据之前,这些初始值不存在.
像这样的一些语法会很棒:
<Route path="/myForm" component={App} async={dispatch(loadInitialFormValues(formId))}>
Run Code Online (Sandbox Code Playgroud) 我有一个叫做的事件UserWasRegistered我也有一个UserWasRegistered从那里调用的监听器,我用它来开发一个叫做的命令:
EmailRegistrationConfirmation
NotifyAdminsNewRegistration
CreateNewBillingAccount
所有这些作业都将在UserWasRegistered事件监听器类中执行.
这是正确的方法还是我应该有多个听众UserWasRegistered?我觉得使用工作方法使我能够在不同的时间从我的应用程序中的其他区域调用那些"工作".例如,CreateNewBillingAccount如果用户更改了他们的详细信息,可能会调用...?
有时我的组件具有大量属性.
这有什么固有的问题吗?
例如
render() {
const { create, update, categories, locations, sectors, workTypes, organisation } = this.props; // eslint-disable-line no-shadow
return (
<div className="job-container">
<JobForm
organisationId={organisation.id}
userId={user.id}
action={action}
create={create}
update={update}
categories={categories}
locations={locations}
sectors={sectors}
workTypes={workTypes}
/>
</div>
);
}
Run Code Online (Sandbox Code Playgroud)
什么是最佳做法?
如何使用normalizr处理标准的关键嵌套标准化JSON API响应{ data: ... }?
例如a Book
{
data: {
title: 'Lord of the Rings',
pages: 9250,
publisher: {
data: {
name: 'HarperCollins LLC',
address: 'Big building next to the river',
city: 'Amsterdam'
},
},
author: {
data: {
name: 'J.R.R Tolkien',
country: 'UK',
age: 124,
}
}
}
}
Run Code Online (Sandbox Code Playgroud)
我如何设计模式来处理嵌套数据键?
注意请不要建议使用 Eloquent,这是专门针对 Laravel 查询构建器的。
出于性能原因,我们使用查询生成器从表中检索结果:
DB::table('posts')->get();
Run Code Online (Sandbox Code Playgroud)
如果我们想将关系连接到该查询上:
DB:table('posts')
->leftJoin('comments', 'posts.id', '=', 'comments.post_id')
->get();
Run Code Online (Sandbox Code Playgroud)
结果被合并到每个帖子的数组中:
[
'id' => 1,
'title' => 'My Blog Post',
'content' => '<h1>This is a post</h1><p>hello world</p>',
'post_author' => 'Billy',
'comment' => 'This is a comment',
'comment_author' => 'Andrew',
]
Run Code Online (Sandbox Code Playgroud)
我们如何将连接的结果放入嵌套数组中?例如:
[
'id' => 1,
'title' => 'My Blog Post',
'content' => '<h1>This is a post</h1><p>hello world</p>',
'post_author' => 'Billy',
'comment' => [
'id' => 22,
'comment' => 'This is a comment',
'comment_author' => 'Andrew',
], …Run Code Online (Sandbox Code Playgroud) 在PHP / Laravel MVC应用程序中,响应代码和主体通常由抛出的Exception决定。如果抛出了HTTP异常(继承自Symfony\Component\HttpKernel\Exception\HttpException),则抛出正确的响应代码(在某些情况下为JSON响应)。还有其他与HTTP不相关的异常类型也可以引发。
HTTP异常应该在哪里抛出?
我是否应该在控制器中捕获异常并抛出这些异常的HTTP版本?还是考虑到99%的MVC框架应用程序都基于HTTP请求>>响应生命周期,我是否应该在服务类,存储库或实用程序中的任何地方抛出HTTP异常?
首先,这是在 Kubernetes 内运行的单一存储库应用程序的上下文中。
在 GitOps 中,我的理解是一切都是声明性的,并写入配置文件(例如 YAML)中。这允许 git 内完整的更改历史记录。分支代表环境。例如:
问题我记得读过...某处...配置应该位于主存储库之外,在另一个“配置存储库”内。从记忆中,这个想法是应用程序不应该知道特定的配置......只知道如何使用配置?
这是真的?我应该有一个应用程序存储库和一个应用程序配置存储库吗?例如
foo-organisation/bar-applicationfoo-organisation/bar-application-config不同环境的配置分支模型位于该存储库中的哪个位置?为什么以及优点是什么?
否则它应该只存在于应用程序存储库的目录中吗?
Docker 最佳实践指南指出:
"......你应该只在一个容器中运行一个进程......"
Nginx和PHP-FPM应该在不同的容器中运行吗?或者这是否意味着微服务架构只在容器中运行一个服务或"app"?
将这些服务放在单个容器中似乎更容易部署和维护.
问题:
在大型React/Redux应用程序中组织容器,组件,操作和减速器的最可维护和建议的最佳实践是 什么?
我的看法:
目前的趋势似乎是围绕相关的容器组件组织redux抵押品(行动,减少器,传奇......).例如
/src
/components
/...
/contianers
/BookList
actions.js
constants.js
reducer.js
selectors.js
sagas.js
index.js
/BookSingle
actions.js
constants.js
reducer.js
selectors.js
sagas.js
index.js
app.js
routes.js
Run Code Online (Sandbox Code Playgroud)
这很棒!虽然这种设计似乎存在一些问题.
问题:
当我们需要访问时actions,selectors或者sagas从另一个容器访问时,它似乎是一种反模式.假设我们有一个/App带有reducer/state 的全局容器,它存储我们在整个应用程序中使用的信息,例如类别和枚举.继上面的例子之后,使用状态树:
{
app: {
taxonomies: {
genres: [genre, genre, genre],
year: [year, year, year],
subject: [subject,subject,subject],
}
}
books: {
entities: {
books: [book, book, book, book],
chapters: [chapter, chapter, chapter],
authors: [author,author,author],
}
},
book: {
entities: {
book: book,
chapters: …Run Code Online (Sandbox Code Playgroud) reactjs ×5
redux ×5
javascript ×4
php ×4
laravel ×3
flux ×2
architecture ×1
arrays ×1
coding-style ×1
components ×1
docker ×1
dockerfile ×1
exception ×1
git ×1
github ×1
gitops ×1
http ×1
kubernetes ×1
laravel-5 ×1
monorepo ×1
mysql ×1
nginx ×1
normalizr ×1
react-router ×1
redux-saga ×1
redux-thunk ×1
reselect ×1
state ×1