React router #343
|
@ -75,29 +75,42 @@ export function clearShowAsset () {
|
||||||
![]() 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
|
|||||||
|
|
||||||
// request for a channel
|
// request for a channel
|
||||||
|
|
||||||
|
export function newChannelRequest (id, name, channelId) {
|
||||||
![]() 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 {
|
||||||
![]() 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
|
|||||||
|
type: actions.NEW_CHANNEL_REQUEST,
|
||||||
![]() 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: {id, name, channelId},
|
||||||
![]() 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
|
|||||||
|
|
||||||
![]() 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 addChannelRequest (id, error, name, claimId) {
|
||||||
![]() 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 {
|
||||||
![]() 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
|
|||||||
|
type: actions.CHANNEL_REQUEST_ADD,
|
||||||
![]() 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: { id, error, name, claimId },
|
||||||
![]() 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
|
|||||||
|
|
||||||
// show a channel
|
// show a channel
|
||||||
|
|
||||||
export function updateShowChannelError (error) {
|
// export function updateShowChannelError (error) {
|
||||||
![]() 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
|
|||||||
return {
|
// return {
|
||||||
![]() 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
|
|||||||
type: actions.SHOW_CHANNEL_ERROR,
|
// type: actions.SHOW_CHANNEL_ERROR,
|
||||||
![]() 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
|
|||||||
data: error,
|
// data: error,
|
||||||
![]() 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
![]() 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
|
|||||||
|
//
|
||||||
![]() 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
|
|||||||
export function updateChannelData (name, longId, shortId) {
|
// export function updateChannelData (name, longId, shortId) {
|
||||||
![]() 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
|
|||||||
return {
|
// return {
|
||||||
![]() 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
|
|||||||
type: actions.CHANNEL_DATA_UPDATE,
|
// type: actions.CHANNEL_DATA_UPDATE,
|
||||||
![]() 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
|
|||||||
data: { name, longId, shortId },
|
// data: { name, longId, shortId },
|
||||||
![]() 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
![]() 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
|
|||||||
|
//
|
||||||
![]() 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
|
|||||||
export function updateChannelClaimsData (claims, currentPage, totalPages, totalClaims) {
|
// export function updateChannelClaimsData (claims, currentPage, totalPages, totalClaims) {
|
||||||
![]() 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
|
|||||||
return {
|
// return {
|
||||||
![]() 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
|
|||||||
type: actions.CHANNEL_CLAIMS_DATA_UPDATE,
|
// type: actions.CHANNEL_CLAIMS_DATA_UPDATE,
|
||||||
![]() 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
|
|||||||
data: { claims, currentPage, totalPages, totalClaims },
|
// data: { claims, currentPage, totalPages, totalClaims },
|
||||||
![]() 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
![]() 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
|
|||||||
|
|
||||||
// display a file
|
// display a file
|
||||||
|
|
||||||
|
|
||||||
![]() 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
|
|
@ -1,6 +1,6 @@
|
||||||
import Request from 'utils/request';
|
import Request from 'utils/request';
|
||||||
|
|
||||||
export function getLongClaimId (name, modifier) {
|
export function getLongChannelClaimId (name, modifier) {
|
||||||
let body = {};
|
let body = {};
|
||||||
// create request params
|
// create request params
|
||||||
if (modifier) {
|
if (modifier) {
|
||||||
|
@ -25,12 +25,12 @@ export function getLongClaimId (name, modifier) {
|
||||||
return Request(url, params);
|
return Request(url, params);
|
||||||
};
|
};
|
||||||
|
|
||||||
export function getShortId (name, claimId) {
|
export function getShortChannelId (name, claimId) {
|
||||||
const url = `/api/claim/short-id/${claimId}/${name}`;
|
const url = `/api/claim/short-id/${claimId}/${name}`;
|
||||||
return Request(url);
|
return Request(url);
|
||||||
};
|
};
|
||||||
|
|
||||||
export function getClaimData (name, claimId) {
|
export function getChannelData (name, claimId) {
|
||||||
const url = `/api/claim/data/${name}/${claimId}`;
|
const url = `/api/claim/data/${name}/${claimId}`;
|
||||||
return Request(url);
|
return Request(url);
|
||||||
};
|
};
|
||||||
|
|
|
@ -18,3 +18,7 @@ export const NEW_ASSET_REQUEST = 'NEW_ASSET_REQUEST';
|
||||||
export const ASSET_REQUEST_ADD = 'ASSET_REQUEST_ADD';
|
export const ASSET_REQUEST_ADD = 'ASSET_REQUEST_ADD';
|
||||||
export const SHOW_NEW_ASSET = 'SHOW_NEW_ASSET';
|
export const SHOW_NEW_ASSET = 'SHOW_NEW_ASSET';
|
||||||
export const SHOW_ASSET_CLEAR = 'SHOW_ASSET_CLEAR';
|
export const SHOW_ASSET_CLEAR = 'SHOW_ASSET_CLEAR';
|
||||||
|
|
||||||
|
export const NEW_CHANNEL_REQUEST = 'NEW_CHANNEL_REQUEST';
|
||||||
|
export const CHANNEL_REQUEST_ADD = 'CHANNEL_REQUEST_ADD';
|
||||||
|
|
||||||
|
|
|
@ -38,12 +38,12 @@ class ShowAsset extends React.Component {
|
||||||
![]() I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
![]() Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
![]() I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
![]() Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
|
|||||||
console.log('repeat request');
|
console.log('repeat request');
|
||||||
const { assets } = this.props;
|
const { assets } = this.props;
|
||||||
const { error: requestError, name, claimId } = request;
|
const { error: requestError, name, claimId } = request;
|
||||||
const assetId = `a#${name}#${claimId}`;
|
|
||||||
![]() I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
![]() Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
|
|||||||
// if error, return and update state with error
|
// if error, return and update state with error
|
||||||
if (requestError) {
|
if (requestError) {
|
||||||
return this.props.onRequestError(requestError);
|
return this.props.onRequestError(requestError);
|
||||||
}
|
}
|
||||||
// update the show asset data in the store
|
// update the showAsset data in the store
|
||||||
![]() I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
![]() Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
![]() I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
![]() Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
|
|||||||
|
const assetId = `a#${name}#${claimId}`;
|
||||||
![]() I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
![]() Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
|
|||||||
if (assets[assetId]) { // case: the asset data already exists
|
if (assets[assetId]) { // case: the asset data already exists
|
||||||
let { error, name, claimId, shortId, claimData } = assets[assetId];
|
let { error, name, claimId, shortId, claimData } = assets[assetId];
|
||||||
this.props.onShowExistingAsset(assetId, error, name, claimId, shortId, claimData);
|
this.props.onShowExistingAsset(assetId, error, name, claimId, shortId, claimData);
|
||||||
|
|
||||||
![]() I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
![]() Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
![]() I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
![]() Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
|
|
@ -1,12 +1,15 @@
|
||||||
import { connect } from 'react-redux';
|
import { connect } from 'react-redux';
|
||||||
import {updateChannelData, updateShowChannelError} from 'actions/show';
|
import {newChannelRequest, updateRequestError} from 'actions/show';
|
||||||
import View from './view';
|
import View from './view';
|
||||||
|
|
||||||
const mapStateToProps = ({ show }) => {
|
const mapStateToProps = ({ show }) => {
|
||||||
return {
|
return {
|
||||||
requestId : show.request.id,
|
requestId : show.request.id,
|
||||||
|
requestType : show.request.type,
|
||||||
requestChannelName: show.request.data.name,
|
requestChannelName: show.request.data.name,
|
||||||
requestChannelId : show.request.data.id,
|
requestChannelId : show.request.data.id,
|
||||||
|
requestList : show.channelRequests,
|
||||||
|
channels : show.channels,
|
||||||
error : show.showChannel.error,
|
error : show.showChannel.error,
|
||||||
name : show.showChannel.channelData.name,
|
name : show.showChannel.channelData.name,
|
||||||
shortId : show.showChannel.channelData.shortId,
|
shortId : show.showChannel.channelData.shortId,
|
||||||
|
@ -16,15 +19,22 @@ const mapStateToProps = ({ show }) => {
|
||||||
|
|
||||||
const mapDispatchToProps = dispatch => {
|
const mapDispatchToProps = dispatch => {
|
||||||
return {
|
return {
|
||||||
onShowChannelError: (error) => {
|
// onShowChannelError: (error) => {
|
||||||
dispatch(updateShowChannelError(error));
|
// dispatch(updateShowChannelError(error));
|
||||||
|
// },
|
||||||
|
// onChannelDataUpdate: (name, longId, shortId) => {
|
||||||
|
// dispatch(updateChannelData(name, longId, shortId));
|
||||||
|
// dispatch(updateShowChannelError(null)); // clear any errors
|
||||||
|
// },
|
||||||
|
// onChannelDataClear: () => {
|
||||||
|
// dispatch(updateChannelData(null, null, null));
|
||||||
|
// },
|
||||||
|
// new
|
||||||
|
onNewChannelRequest (id, name, channelId) {
|
||||||
|
dispatch(newChannelRequest(id, name, channelId));
|
||||||
},
|
},
|
||||||
onChannelDataUpdate: (name, longId, shortId) => {
|
onRequestError: (error) => {
|
||||||
dispatch(updateChannelData(name, longId, shortId));
|
dispatch(updateRequestError(error, null, null));
|
||||||
dispatch(updateShowChannelError(null)); // clear any errors
|
|
||||||
},
|
|
||||||
onChannelDataClear: () => {
|
|
||||||
dispatch(updateChannelData(null, null, null));
|
|
||||||
},
|
},
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
|
@ -4,17 +4,59 @@ import NavBar from 'containers/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.
![]() 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.
|
|||||||
import ChannelClaimsDisplay from 'containers/ChannelClaimsDisplay';
|
import ChannelClaimsDisplay from 'containers/ChannelClaimsDisplay';
|
||||||
import request from 'utils/request';
|
import request from 'utils/request';
|
||||||
|
|
||||||
|
import { CHANNEL } from 'constants/show_request_types';
|
||||||
![]() 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.
|
|||||||
|
function requestIsAChannelRequest ({ requestType }) {
|
||||||
![]() 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 requestType === 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.
|
|||||||
|
}
|
||||||
![]() 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.
|
|||||||
|
function channelNameOrIdChanged (nextProps, 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.
|
|||||||
|
return (nextProps.requestChannelName !== props.requestChannelName || nextProps.requestChannelName !== props.requestChannelName);
|
||||||
![]() 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.
|
|||||||
|
function existingRequest (requestId, requestList) {
|
||||||
![]() 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 requestList[requestId];
|
||||||
![]() 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.
|
|||||||
class ShowChannel extends React.Component {
|
class ShowChannel extends React.Component {
|
||||||
componentDidMount () {
|
componentDidMount () {
|
||||||
console.log('showchannel did mount');
|
console.log('showchannel did mount');
|
||||||
const {requestChannelName, requestChannelId} = this.props;
|
const {requestId, requestName, requestChannelId, requestList} = 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.
![]() 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.getAndStoreChannelData(requestChannelName, requestChannelId);
|
if (existingRequest(requestId, requestList)) {
|
||||||
![]() 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 validRequest = existingRequest(requestId, requestList);
|
||||||
![]() 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.onRepeatChannelRequest(validRequest);
|
||||||
![]() 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.
|
|||||||
|
console.log('weird, we got a repeat channel request on an unmounted ShowChannel 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.
|
|||||||
|
} else {
|
||||||
![]() 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.onNewChannelRequest(requestId, requestName, requestChannelId);
|
||||||
![]() 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.
|
|||||||
}
|
}
|
||||||
componentWillReceiveProps (nextProps) {
|
componentWillReceiveProps (nextProps) {
|
||||||
if (nextProps.channelRequests !== this.props.channelRequests) {
|
console.log('showchannel will receive new 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.
![]() 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 {requestChannelName, requestChannelId} = nextProps;
|
if (requestIsAChannelRequest(nextProps) && channelNameOrIdChanged(nextProps, 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.
![]() 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.getAndStoreChannelData(requestChannelName, requestChannelId);
|
const {requestId, requestList} = nextProps;
|
||||||
![]() 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.
|
|||||||
|
if (existingRequest(requestId, requestList)) {
|
||||||
![]() 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 request = requestList[requestId];
|
||||||
![]() 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.onRepeatChannelRequest(request);
|
||||||
![]() 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 {
|
||||||
![]() 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.
|
|||||||
|
console.log('weird, we got a new channel request on a mounted ShowChannel 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.
|
|||||||
|
}
|
||||||
![]() 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.
|
|||||||
|
onNewChannelRequest (requestId, requestName, requestChannelId) {
|
||||||
![]() 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.
|
|||||||
|
// validate the request (i.e. get channel full claim id)
|
||||||
![]() 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.
|
|||||||
|
// update teh request list
|
||||||
![]() 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 early (set the request error in the store)
|
||||||
![]() 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 the request is valid...
|
||||||
![]() 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.
|
|||||||
|
// add it to the requestList
|
||||||
![]() 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.
|
|||||||
|
// update showChannel to reflect the channel details
|
||||||
![]() 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.onNewChannelRequest(requestId, requestName, requestChannelId);
|
||||||
![]() 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.
|
|||||||
|
onRepeatChannelRequest ({ id, error, name, claimId }) {
|
||||||
![]() 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 early (set the request error in the store)
|
||||||
![]() 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 the request is valid...
|
||||||
![]() 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.
|
|||||||
|
// update showChannel to reflect the channel details
|
||||||
![]() 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.
|
|||||||
|
// see if they are available
|
||||||
![]() 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.
|
|||||||
|
// retrieve them if they are not available
|
||||||
![]() 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.
|
|||||||
}
|
}
|
||||||
getAndStoreChannelData (name, id) {
|
getAndStoreChannelData (name, id) {
|
||||||
console.log('getting and storing channel data for channel:', name, id);
|
console.log('getting and storing channel data for channel:', name, id);
|
||||||
|
|
||||||
![]() 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.
|
|
@ -9,21 +9,6 @@ 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
|
|||||||
data : null,
|
data : null,
|
||||||
requestId: null,
|
requestId: null,
|
||||||
},
|
},
|
||||||
// channelRequest: {
|
|
||||||
![]() 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
|
|||||||
// 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
|
|||||||
// },
|
|
||||||
![]() 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
|
|||||||
// assetRequest: {
|
|
||||||
![]() 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
|
|||||||
// modifier: {
|
|
||||||
![]() 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
|
|||||||
// channel: {
|
|
||||||
![]() 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
|
|||||||
// 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
|
|||||||
// },
|
|
||||||
![]() 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
|
|||||||
// extension: 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
|
|||||||
showChannel: {
|
showChannel: {
|
||||||
error : null,
|
error : null,
|
||||||
channelData: {
|
channelData: {
|
||||||
|
@ -135,26 +120,35 @@ 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
|
|||||||
}),
|
}),
|
||||||
});
|
});
|
||||||
// request a channel
|
// request a channel
|
||||||
|
case actions.CHANNEL_REQUEST_ADD:
|
||||||
![]() 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
|
|||||||
|
return Object.assign({}, state, {
|
||||||
![]() 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
|
|||||||
|
channelRequests: Object.assign({}, state.assetRequests, {
|
||||||
![]() 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
|
|||||||
|
[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
|
|||||||
|
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
|
|||||||
|
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
|
|||||||
|
claimId: action.data.claimId,
|
||||||
![]() 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
|
|||||||
|
}),
|
||||||
![]() 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
|
|||||||
// show a channel
|
// show a channel
|
||||||
case actions.SHOW_CHANNEL_ERROR:
|
// case actions.SHOW_CHANNEL_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
![]() 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
|
|||||||
return Object.assign({}, state, {
|
// return Object.assign({}, state, {
|
||||||
![]() 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
|
|||||||
showChannel: Object.assign({}, state.showChannel, {
|
// showChannel: Object.assign({}, state.showChannel, {
|
||||||
![]() 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: action.data,
|
// error: action.data,
|
||||||
![]() 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
|
|||||||
}),
|
// }),
|
||||||
![]() 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
|
|||||||
});
|
// });
|
||||||
![]() 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.CHANNEL_DATA_UPDATE:
|
// case actions.CHANNEL_DATA_UPDATE:
|
||||||
![]() 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
|
|||||||
return Object.assign({}, state, {
|
// return Object.assign({}, state, {
|
||||||
![]() 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
|
|||||||
showChannel: Object.assign({}, state.showChannel, {
|
// showChannel: Object.assign({}, state.showChannel, {
|
||||||
![]() 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
|
|||||||
channelData: action.data,
|
// channelData: action.data,
|
||||||
![]() 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
|
|||||||
}),
|
// }),
|
||||||
![]() 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
|
|||||||
});
|
// });
|
||||||
![]() 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.CHANNEL_CLAIMS_DATA_UPDATE:
|
// case actions.CHANNEL_CLAIMS_DATA_UPDATE:
|
||||||
![]() 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
|
|||||||
return Object.assign({}, state, {
|
// return Object.assign({}, state, {
|
||||||
![]() 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
|
|||||||
showChannel: Object.assign({}, state.showChannel, {
|
// showChannel: Object.assign({}, state.showChannel, {
|
||||||
![]() 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
|
|||||||
channelClaimsData: action.data,
|
// channelClaimsData: action.data,
|
||||||
![]() 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
|
|||||||
}),
|
// }),
|
||||||
![]() 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
|
|||||||
});
|
// });
|
||||||
![]() 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
|
|||||||
// display an asset
|
// display an asset
|
||||||
case actions.FILE_AVAILABILITY_UPDATE:
|
case actions.FILE_AVAILABILITY_UPDATE:
|
||||||
return Object.assign({}, state, {
|
return Object.assign({}, state, {
|
||||||
|
|
||||||
![]() 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
|
|
@ -1,9 +1,10 @@
|
||||||
import { call, put, takeLatest } from 'redux-saga/effects';
|
import { call, put, takeLatest } from 'redux-saga/effects';
|
||||||
import * as actions from 'constants/show_action_types';
|
import * as actions from 'constants/show_action_types';
|
||||||
import { addAssetRequest, updateShowAsset, updateFileAvailability, updateDisplayAssetError } from 'actions/show';
|
import { addAssetRequest, updateShowAsset, addChannelRequest, updateShowChannel, updateFileAvailability, updateDisplayAssetError } from 'actions/show';
|
||||||
import { UNAVAILABLE, AVAILABLE } from 'constants/asset_display_states';
|
import { UNAVAILABLE, AVAILABLE } from 'constants/asset_display_states';
|
||||||
import { checkFileAvailability, triggerClaimGet } from 'api/fileApi';
|
import { checkFileAvailability, triggerClaimGet } from 'api/fileApi';
|
||||||
import { getLongClaimId, getShortId, getClaimData } from 'api/assetApi';
|
import { getLongClaimId, getShortId, getClaimData } from 'api/assetApi';
|
||||||
|
import { getLongChannelClaimId, getShortChannelId, getChannelData } from 'api/channelApi';
|
||||||
|
|
||||||
function* newAssetRequest (action) {
|
function* newAssetRequest (action) {
|
||||||
const { id, name, modifier } = action.data;
|
const { id, name, modifier } = action.data;
|
||||||
|
@ -11,7 +12,6 @@ function* newAssetRequest (action) {
|
||||||
try {
|
try {
|
||||||
({success, message, data: longId} = yield call(getLongClaimId, name, modifier));
|
({success, message, data: longId} = yield call(getLongClaimId, name, modifier));
|
||||||
} catch (error) {
|
} catch (error) {
|
||||||
console.log('error making getLongClaimId call', error);
|
|
||||||
yield put(addAssetRequest(id, error.message, name, null));
|
yield put(addAssetRequest(id, error.message, name, null));
|
||||||
}
|
}
|
||||||
if (success) {
|
if (success) {
|
||||||
|
@ -20,6 +20,20 @@ function* newAssetRequest (action) {
|
||||||
yield put(addAssetRequest(id, message, name, null));
|
yield put(addAssetRequest(id, message, name, null));
|
||||||
};
|
};
|
||||||
|
|
||||||
|
function* newChannelRequest (action) {
|
||||||
|
const { id, name, channelId } = action.data;
|
||||||
|
let success, message, longChannelId;
|
||||||
|
try {
|
||||||
|
({success, message, data: longChannelId} = yield call(getLongChannelClaimId, name, channelId));
|
||||||
|
} catch (error) {
|
||||||
|
yield put(addChannelRequest(id, error.message, name, null));
|
||||||
|
}
|
||||||
|
if (success) {
|
||||||
|
return yield put(addChannelRequest(id, null, name, longChannelId));
|
||||||
|
}
|
||||||
|
yield put(addChannelRequest(id, message, name, null));
|
||||||
|
}
|
||||||
|
|
||||||
function* getAssetDataAndShowAsset (action) {
|
function* getAssetDataAndShowAsset (action) {
|
||||||
const {id, name, claimId} = action.data;
|
const {id, name, claimId} = action.data;
|
||||||
// if no error, get short Id
|
// if no error, get short Id
|
||||||
|
@ -83,6 +97,10 @@ export function* watchNewAssetRequest () {
|
||||||
yield takeLatest(actions.NEW_ASSET_REQUEST, newAssetRequest);
|
yield takeLatest(actions.NEW_ASSET_REQUEST, newAssetRequest);
|
||||||
};
|
};
|
||||||
|
|
||||||
|
export function* watchNewChannelRequest () {
|
||||||
|
yield takeLatest(actions.NEW_CHANNEL_REQUEST, newChannelRequest);
|
||||||
|
};
|
||||||
|
|
||||||
export function* watchShowNewAsset () {
|
export function* watchShowNewAsset () {
|
||||||
yield takeLatest(actions.SHOW_NEW_ASSET, getAssetDataAndShowAsset);
|
yield takeLatest(actions.SHOW_NEW_ASSET, getAssetDataAndShowAsset);
|
||||||
};
|
};
|
||||||
|
|
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