React router #343
|
|
@ -109,10 +109,10 @@ export function showNewChannel (channelData) {
|
|||
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
};
|
||||
};
|
||||
|
||||
export function updateShowChannel (error, name, shortId, longId, claimsData) {
|
||||
|
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
export function updateShowChannel (error, id) {
|
||||
|
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
return {
|
||||
type: actions.SHOW_CHANNEL_UPDATE,
|
||||
data: { error, name, shortId, longId, claimsData },
|
||||
|
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
data: { error, id },
|
||||
|
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
|
|
@ -2,15 +2,9 @@ import { connect } from 'react-redux';
|
|||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
import { } from 'actions/show';
|
||||
import View from './view';
|
||||
|
||||
const mapStateToProps = ({ show : { showChannel: { error, channelData, claimsData } } }) => {
|
||||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
const mapStateToProps = ({ show }) => {
|
||||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
return {
|
||||
error : error,
|
||||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
name : channelData.name,
|
||||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
longId : channelData.longId,
|
||||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
claims : claimsData.claims,
|
||||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
currentPage: claimsData.currentPage,
|
||||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
totalPages : claimsData.totalPages,
|
||||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
totalClaims: claimsData.totalClaims,
|
||||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
channel: show.channelList[show.showChannel.id],
|
||||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
Will these nested values always exist? Will these nested values always exist?
They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking? They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
I was just wondering if there would ever be a case when Or if any of those children would be undefined which would throw an error I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`.
Or if any of those children would be undefined which would throw an error
|
||||
|
|
@ -20,7 +20,7 @@ class ChannelClaimsDisplay extends React.Component {
|
|||
|
This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
|
||||
this.showNewPage(nextPage);
|
||||
}
|
||||
render () {
|
||||
const { error, claims, currentPage, totalPages } = this.props;
|
||||
|
This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
|
||||
const { channel: { error, claimsData: { claims, currentPage, totalPages } } } = this.props;
|
||||
|
This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
|
||||
return (
|
||||
<div>
|
||||
{error ? (
|
||||
|
|
|
|||
|
This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
|
||||
|
|
@ -13,25 +13,26 @@ const mapStateToProps = ({ show }) => {
|
|||
channelList : show.channelList,
|
||||
// show channel
|
||||
error : show.showChannel.error,
|
||||
name : show.showChannel.channelData.name,
|
||||
shortId : show.showChannel.channelData.shortId,
|
||||
longId : show.showChannel.channelData.longId,
|
||||
id : show.showChannel.id,
|
||||
channel : show.channelList[show.showChannel.id],
|
||||
};
|
||||
};
|
||||
|
||||
const mapDispatchToProps = dispatch => {
|
||||
return {
|
||||
// request
|
||||
onNewChannelRequest (id, name, channelId) {
|
||||
dispatch(newChannelRequest(id, name, channelId));
|
||||
},
|
||||
onRequestError: (error) => {
|
||||
dispatch(updateRequestError(error, null, null));
|
||||
},
|
||||
// show channel
|
||||
onShowNewChannel: (channelData) => {
|
||||
dispatch(showNewChannel(channelData));
|
||||
},
|
||||
onShowExistingChannel: (error, name, shortId, longId, claimsData) => {
|
||||
dispatch(updateShowChannel(error, name, shortId, longId, claimsData));
|
||||
onShowExistingChannel: (id) => {
|
||||
dispatch(updateShowChannel(null, id));
|
||||
},
|
||||
onShowChannelClear: () => {
|
||||
dispatch(clearShowChannel());
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ class ShowChannel extends React.Component {
|
|||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
const channelRecordId = `c#${channelData.name}#${channelData.longId}`;
|
||||
const existingChannel = channelList[channelRecordId];
|
||||
if (existingChannel) {
|
||||
this.showExistingChannel(existingChannel);
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
this.showExistingChannel(channelRecordId);
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
} else {
|
||||
this.showNewChannel(channelData);
|
||||
}
|
||||
|
|
@ -57,34 +57,39 @@ class ShowChannel extends React.Component {
|
|||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
showNewChannel (channelData) {
|
||||
this.props.onShowNewChannel(channelData);
|
||||
};
|
||||
showExistingChannel (existingChannel) {
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
const { error, channelData: {name, shortId, longId}, claimsData } = existingChannel;
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
this.props.onShowExistingChannel(error, name, shortId, longId, claimsData);
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
showExistingChannel (channelRecordId) {
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
this.props.onShowExistingChannel(channelRecordId);
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
};
|
||||
componentWillUnmount () {
|
||||
this.props.onShowChannelClear();
|
||||
}
|
||||
render () {
|
||||
const { error, name, longId, shortId } = this.props;
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
const { error, channel } = this.props;
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
if (error) {
|
||||
return (
|
||||
<ErrorPage error={error}/>
|
||||
);
|
||||
};
|
||||
return (
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<div>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<NavBar/>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<div className="row row--tall row--padded">
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<div className="column column--10">
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<h2>channel name: {name ? name : 'loading...'}</h2>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<p className={'fine-print'}>full channel id: {longId ? longId : 'loading...'}</p>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<p className={'fine-print'}>short channel id: {shortId ? shortId : 'loading...'}</p>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
</div>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<div className="column column--10">
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
{(name && longId) && <ChannelClaimsDisplay />}
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
if (channel) {
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
const { channelData: { name, longId, shortId } } = channel;
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
return (
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<div>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<NavBar/>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<div className="row row--tall row--padded">
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<div className="column column--10">
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<h2>channel name: {name ? name : 'loading...'}</h2>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<p className={'fine-print'}>full channel id: {longId ? longId : 'loading...'}</p>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<p className={'fine-print'}>short channel id: {shortId ? shortId : 'loading...'}</p>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
</div>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<div className="column column--10">
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
{(name && longId) && <ChannelClaimsDisplay />}
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
</div>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
);
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
};
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
return (
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
<ErrorPage error={'loading channel data...'}/>
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
);
|
||||
}
|
||||
};
|
||||
|
|
|
|||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
|
|
@ -10,18 +10,8 @@ const initialState = {
|
|||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
requestId: null,
|
||||
},
|
||||
showChannel: {
|
||||
error : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
channelData: {
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
name : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
shortId: null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
longId : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
},
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
claimsData: {
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
claims : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
currentPage: null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
totalPages : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
totalClaims: null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
},
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
error: null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
id : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
},
|
||||
showAsset: {
|
||||
error: null,
|
||||
|
|
@ -132,30 +122,15 @@ export default function (state = initialState, action) {
|
|||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
case actions.SHOW_CHANNEL_UPDATE:
|
||||
return Object.assign({}, state, {
|
||||
showChannel: {
|
||||
error : action.data.error,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
channelData: {
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
name : action.data.name,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
shortId: action.data.shortId,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
longId : action.data.longId,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
},
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
claimsData: action.data.claimsData,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
error: action.data.error,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
id : action.data.id,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
},
|
||||
});
|
||||
case actions.SHOW_CHANNEL_CLEAR:
|
||||
return Object.assign({}, state, {
|
||||
showChannel: {
|
||||
error : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
channelData: {
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
name : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
shortId: null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
longId : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
},
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
claimsData: {
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
claims : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
currentPage: null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
totalPages : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
totalClaims: null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
},
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
error: null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
id : null,
|
||||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
},
|
||||
});
|
||||
// add channel to channel list
|
||||
|
|
|
|||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
|
|
@ -26,8 +26,8 @@ function* getAssetDataAndShowAsset (action) {
|
|||
if (!success) {
|
||||
return yield put(updateShowAsset(message, null));
|
||||
}
|
||||
yield put(updateShowAsset(null, id));
|
||||
yield put(upsertAssetToAssetList(id, null, name, claimId, shortId, claimData));
|
||||
yield put(updateShowAsset(null, id));
|
||||
}
|
||||
|
||||
export function* watchShowNewAsset () {
|
||||
|
|
|
|||
|
|
@ -9,14 +9,14 @@ function* getNewChannelDataAndShowChannel (action) {
|
|||
|
I don't have any experience using Generally you want I don't have any experience using `redux-saga` so I might just not understand what is happening.
Generally you want `XX_SUCCESS` and `XX_FAIL` actions separated. That makes it a lot easier handling the data on the reducer.
If these aren't being used anywhere else, I don't think they need to be separated. IMO it would make these saga files easier to understand/follow, but not a big issue If these aren't being used anywhere else, I don't think they need to be separated.
IMO it would make these saga files easier to understand/follow, but not a big issue
I don't have any experience using Generally you want I don't have any experience using `redux-saga` so I might just not understand what is happening.
Generally you want `XX_SUCCESS` and `XX_FAIL` actions separated. That makes it a lot easier handling the data on the reducer.
If these aren't being used anywhere else, I don't think they need to be separated. IMO it would make these saga files easier to understand/follow, but not a big issue If these aren't being used anywhere else, I don't think they need to be separated.
IMO it would make these saga files easier to understand/follow, but not a big issue
|
||||
try {
|
||||
({ success, message, data: claimsData } = yield call(getChannelClaims, name, longId, 1));
|
||||
} catch (error) {
|
||||
return yield put(updateShowChannel(error.message, name, shortId, longId));
|
||||
|
I don't have any experience using Generally you want I don't have any experience using `redux-saga` so I might just not understand what is happening.
Generally you want `XX_SUCCESS` and `XX_FAIL` actions separated. That makes it a lot easier handling the data on the reducer.
If these aren't being used anywhere else, I don't think they need to be separated. IMO it would make these saga files easier to understand/follow, but not a big issue If these aren't being used anywhere else, I don't think they need to be separated.
IMO it would make these saga files easier to understand/follow, but not a big issue
|
||||
return yield put(updateShowChannel(error.message, null));
|
||||
|
I don't have any experience using Generally you want I don't have any experience using `redux-saga` so I might just not understand what is happening.
Generally you want `XX_SUCCESS` and `XX_FAIL` actions separated. That makes it a lot easier handling the data on the reducer.
If these aren't being used anywhere else, I don't think they need to be separated. IMO it would make these saga files easier to understand/follow, but not a big issue If these aren't being used anywhere else, I don't think they need to be separated.
IMO it would make these saga files easier to understand/follow, but not a big issue
|
||||
}
|
||||
if (!success) {
|
||||
return yield put(updateShowChannel(message, name, shortId, longId));
|
||||
|
I don't have any experience using Generally you want I don't have any experience using `redux-saga` so I might just not understand what is happening.
Generally you want `XX_SUCCESS` and `XX_FAIL` actions separated. That makes it a lot easier handling the data on the reducer.
If these aren't being used anywhere else, I don't think they need to be separated. IMO it would make these saga files easier to understand/follow, but not a big issue If these aren't being used anywhere else, I don't think they need to be separated.
IMO it would make these saga files easier to understand/follow, but not a big issue
|
||||
return yield put(updateShowChannel(message, null));
|
||||
|
I don't have any experience using Generally you want I don't have any experience using `redux-saga` so I might just not understand what is happening.
Generally you want `XX_SUCCESS` and `XX_FAIL` actions separated. That makes it a lot easier handling the data on the reducer.
If these aren't being used anywhere else, I don't think they need to be separated. IMO it would make these saga files easier to understand/follow, but not a big issue If these aren't being used anywhere else, I don't think they need to be separated.
IMO it would make these saga files easier to understand/follow, but not a big issue
|
||||
}
|
||||
yield put(updateShowChannel(null, name, shortId, longId, claimsData));
|
||||
|
I don't have any experience using Generally you want I don't have any experience using `redux-saga` so I might just not understand what is happening.
Generally you want `XX_SUCCESS` and `XX_FAIL` actions separated. That makes it a lot easier handling the data on the reducer.
If these aren't being used anywhere else, I don't think they need to be separated. IMO it would make these saga files easier to understand/follow, but not a big issue If these aren't being used anywhere else, I don't think they need to be separated.
IMO it would make these saga files easier to understand/follow, but not a big issue
|
||||
const channelData = {name, shortId, longId};
|
||||
yield put(addNewChannelToChannelList(id, null, channelData, claimsData));
|
||||
yield put(updateShowChannel(null, id));
|
||||
|
I don't have any experience using Generally you want I don't have any experience using `redux-saga` so I might just not understand what is happening.
Generally you want `XX_SUCCESS` and `XX_FAIL` actions separated. That makes it a lot easier handling the data on the reducer.
If these aren't being used anywhere else, I don't think they need to be separated. IMO it would make these saga files easier to understand/follow, but not a big issue If these aren't being used anywhere else, I don't think they need to be separated.
IMO it would make these saga files easier to understand/follow, but not a big issue
|
||||
}
|
||||
|
||||
export function* watchShowNewChannel () {
|
||||
|
|
|
|||
|
I don't have any experience using Generally you want I don't have any experience using `redux-saga` so I might just not understand what is happening.
Generally you want `XX_SUCCESS` and `XX_FAIL` actions separated. That makes it a lot easier handling the data on the reducer.
If these aren't being used anywhere else, I don't think they need to be separated. IMO it would make these saga files easier to understand/follow, but not a big issue If these aren't being used anywhere else, I don't think they need to be separated.
IMO it would make these saga files easier to understand/follow, but not a big issue
I don't have any experience using Generally you want I don't have any experience using `redux-saga` so I might just not understand what is happening.
Generally you want `XX_SUCCESS` and `XX_FAIL` actions separated. That makes it a lot easier handling the data on the reducer.
If these aren't being used anywhere else, I don't think they need to be separated. IMO it would make these saga files easier to understand/follow, but not a big issue If these aren't being used anywhere else, I don't think they need to be separated.
IMO it would make these saga files easier to understand/follow, but not a big issue
|
||||
I think generally the pattern is that an action is
{ type: "some string", data: { name, id... } }just to keep things consistent.datacan be an object or a string, but I think it's helpful to put everything inside of that