React router #343
|
@ -1,5 +1,12 @@
|
||||||
![]() 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
|
|||||||
import * as actions from 'constants/show_action_types';
|
import * as actions from 'constants/show_action_types';
|
||||||
|
|
||||||
|
export function updateRequestError (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
|
|||||||
|
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.REQUEST_ERROR_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
|
|||||||
|
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
|
|||||||
export function updateRequestWithChannelRequest (name, id) {
|
export function updateRequestWithChannelRequest (name, id) {
|
||||||
return {
|
return {
|
||||||
type: actions.REQUEST_CHANNEL_UPDATE,
|
type: actions.REQUEST_CHANNEL_UPDATE,
|
||||||
|
@ -27,12 +34,12 @@ export function updateRequestWithAssetRequest (name, id, channelName, 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
|
|||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
export function updateRequestError (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 {
|
||||||
type: actions.REQUEST_ERROR_UPDATE,
|
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
|
|||||||
|
|
||||||
export function updateChannelData (name, longId, shortId) {
|
export function updateChannelData (name, longId, shortId) {
|
||||||
return {
|
return {
|
||||||
|
@ -57,6 +64,13 @@ export function updateChannelClaimsData (claims, currentPage, totalPages, totalC
|
||||||
![]() 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 updateShowAssetError (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
|
|||||||
|
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.SHOW_ASSET_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
|
|||||||
|
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
|
|||||||
export function updateAssetClaimData (data, shortId) {
|
export function updateAssetClaimData (data, shortId) {
|
||||||
return {
|
return {
|
||||||
type: actions.ASSET_CLAIM_DATA_UPDATE,
|
type: actions.ASSET_CLAIM_DATA_UPDATE,
|
||||||
|
@ -84,13 +98,6 @@ export function updateFileAvailability (status) {
|
||||||
![]() 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 updateShowAssetError (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
|
|||||||
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.SHOW_ASSET_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
|
|||||||
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
|
|||||||
export function updateDisplayAssetError (error) {
|
export function updateDisplayAssetError (error) {
|
||||||
return {
|
return {
|
||||||
type: actions.DISPLAY_ASSET_ERROR,
|
type: actions.DISPLAY_ASSET_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
|
|
@ -1,4 +1,5 @@
|
||||||
import React from 'react';
|
import React from 'react';
|
||||||
|
import PropTypes from 'prop-types';
|
||||||
import NavBar from 'containers/NavBar';
|
import NavBar from 'containers/NavBar';
|
||||||
|
|
||||||
class ErrorPage extends React.Component {
|
class ErrorPage extends React.Component {
|
||||||
|
@ -15,7 +16,8 @@ class ErrorPage extends React.Component {
|
||||||
}
|
}
|
||||||
};
|
};
|
||||||
|
|
||||||
// required props
|
ErrorPage.propTypes = {
|
||||||
// error
|
error: PropTypes.string.isRequired,
|
||||||
|
}
|
||||||
|
|
||||||
export default ErrorPage;
|
export default ErrorPage;
|
||||||
|
|
|
@ -1,10 +1,14 @@
|
||||||
export const REQUEST_CHANNEL_UPDATE = 'REQUEST_CHANNEL_UPDATE';
|
export const REQUEST_CHANNEL_UPDATE = 'REQUEST_CHANNEL_UPDATE';
|
||||||
export const REQUEST_CLAIM_UPDATE = 'REQUEST_CLAIM_UPDATE';
|
export const REQUEST_CLAIM_UPDATE = 'REQUEST_CLAIM_UPDATE';
|
||||||
export const REQUEST_ERROR_UPDATE = 'REQUEST_ERROR_UPDATE';
|
export const REQUEST_ERROR_UPDATE = 'REQUEST_ERROR_UPDATE';
|
||||||
|
|
||||||
|
export const SHOW_CHANNEL_ERROR = 'SHOW_CHANNEL_ERROR';
|
||||||
export const CHANNEL_DATA_UPDATE = 'CHANNEL_DATA_UPDATE';
|
export const CHANNEL_DATA_UPDATE = 'CHANNEL_DATA_UPDATE';
|
||||||
export const CHANNEL_CLAIMS_DATA_UPDATE = 'CHANNEL_CLAIMS_DATA_UPDATE';
|
export const CHANNEL_CLAIMS_DATA_UPDATE = 'CHANNEL_CLAIMS_DATA_UPDATE';
|
||||||
|
|
||||||
|
export const SHOW_ASSET_ERROR = 'SHOW_ASSET_ERROR';
|
||||||
export const ASSET_CLAIM_DATA_UPDATE = 'ASSET_CLAIM_DATA_UPDATE';
|
export const ASSET_CLAIM_DATA_UPDATE = 'ASSET_CLAIM_DATA_UPDATE';
|
||||||
|
|
||||||
export const FILE_REQUESTED = 'FILE_REQUESTED';
|
export const FILE_REQUESTED = 'FILE_REQUESTED';
|
||||||
export const FILE_AVAILABILITY_UPDATE = 'FILE_AVAILABILITY_UPDATE';
|
export const FILE_AVAILABILITY_UPDATE = 'FILE_AVAILABILITY_UPDATE';
|
||||||
export const SHOW_ASSET_ERROR = 'SHOW_ASSET_ERROR';
|
|
||||||
export const DISPLAY_ASSET_ERROR = 'DISPLAY_ASSET_ERROR';
|
export const DISPLAY_ASSET_ERROR = 'DISPLAY_ASSET_ERROR';
|
||||||
|
|
|
@ -1,4 +1,5 @@
|
||||||
![]() 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.
|
|||||||
import React from 'react';
|
import React from 'react';
|
||||||
|
import ErrorPage from 'components/ErrorPage';
|
||||||
![]() 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.
|
|||||||
import ShowAssetLite from 'components/ShowAssetLite';
|
import ShowAssetLite from 'components/ShowAssetLite';
|
||||||
import ShowAssetDetails from 'components/ShowAssetDetails';
|
import ShowAssetDetails from 'components/ShowAssetDetails';
|
||||||
import request from 'utils/request';
|
import request from 'utils/request';
|
||||||
|
@ -43,7 +44,6 @@ 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.
|
|||||||
}
|
}
|
||||||
getLongClaimId (params) {
|
getLongClaimId (params) {
|
||||||
const url = `/api/claim/long-id`;
|
const url = `/api/claim/long-id`;
|
||||||
console.log('params:', params);
|
|
||||||
![]() 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.
|
|||||||
return new Promise((resolve, reject) => {
|
return new Promise((resolve, reject) => {
|
||||||
request(url, params)
|
request(url, params)
|
||||||
.then(({ success, message, data }) => {
|
.then(({ success, message, data }) => {
|
||||||
|
@ -97,7 +97,7 @@ 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.
|
|||||||
const { error, claimData, extension } = this.props;
|
const { error, claimData, extension } = this.props;
|
||||||
if (error) {
|
if (error) {
|
||||||
return (
|
return (
|
||||||
<p>{error}</p>
|
<ErrorPage error={error}/>
|
||||||
![]() 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.
|
|||||||
);
|
);
|
||||||
}
|
}
|
||||||
if (claimData) {
|
if (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,11 +1,12 @@
|
||||||
import { connect } from 'react-redux';
|
import { connect } from 'react-redux';
|
||||||
import {updateChannelData} from 'actions/show';
|
import {updateChannelData, updateShowChannelError} from 'actions/show';
|
||||||
import View from './view';
|
import View from './view';
|
||||||
|
|
||||||
const mapStateToProps = ({ show }) => {
|
const mapStateToProps = ({ show }) => {
|
||||||
return {
|
return {
|
||||||
requestName: show.channelRequest.name,
|
requestName: show.channelRequest.name,
|
||||||
requestId : show.channelRequest.id,
|
requestId : show.channelRequest.id,
|
||||||
|
error : show.showChannel.error,
|
||||||
name : show.showChannel.channelData.name,
|
name : show.showChannel.channelData.name,
|
||||||
shortId : show.showChannel.channelData.shortId,
|
shortId : show.showChannel.channelData.shortId,
|
||||||
longId : show.showChannel.channelData.longId,
|
longId : show.showChannel.channelData.longId,
|
||||||
|
@ -14,8 +15,12 @@ const mapStateToProps = ({ show }) => {
|
||||||
|
|
||||||
const mapDispatchToProps = dispatch => {
|
const mapDispatchToProps = dispatch => {
|
||||||
return {
|
return {
|
||||||
|
onShowChannelError: (error) => {
|
||||||
|
dispatch(updateShowChannelError(error));
|
||||||
|
},
|
||||||
onChannelDataUpdate: (name, longId, shortId) => {
|
onChannelDataUpdate: (name, longId, shortId) => {
|
||||||
dispatch(updateChannelData(name, longId, shortId));
|
dispatch(updateChannelData(name, longId, shortId));
|
||||||
|
dispatch(updateShowChannelError(null)); // clear any errors
|
||||||
},
|
},
|
||||||
onChannelDataClear: () => {
|
onChannelDataClear: () => {
|
||||||
dispatch(updateChannelData(null, null, null));
|
dispatch(updateChannelData(null, null, null));
|
||||||
|
|
|
@ -1,15 +1,10 @@
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() 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 React from 'react';
|
import React from 'react';
|
||||||
|
import ErrorPage from 'components/ErrorPage';
|
||||||
![]() 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 NavBar from 'containers/NavBar';
|
import NavBar from 'containers/NavBar';
|
||||||
import ChannelClaimsDisplay from 'containers/ChannelClaimsDisplay';
|
import ChannelClaimsDisplay from 'containers/ChannelClaimsDisplay';
|
||||||
import request from 'utils/request';
|
import request from 'utils/request';
|
||||||
|
|
||||||
class ShowChannel extends React.Component {
|
class ShowChannel extends React.Component {
|
||||||
constructor (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.
|
|||||||
super(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.
|
|||||||
this.state = {
|
|
||||||
![]() 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.
|
|||||||
error: null,
|
|
||||||
![]() 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.
|
|||||||
componentDidMount () {
|
componentDidMount () {
|
||||||
this.getAndStoreChannelData(this.props.requestName, this.props.requestId);
|
this.getAndStoreChannelData(this.props.requestName, this.props.requestId);
|
||||||
}
|
}
|
||||||
|
@ -23,42 +18,39 @@ class ShowChannel extends React.Component {
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
const url = `/api/channel/data/${name}/${id}`;
|
const url = `/api/channel/data/${name}/${id}`;
|
||||||
return request(url)
|
return request(url)
|
||||||
.then(({ success, message, data }) => {
|
.then(({ success, message, data }) => {
|
||||||
console.log('api/channel-data response:', data);
|
console.log('api/channel/data/ response:', data);
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
if (!success) {
|
if (!success) {
|
||||||
return this.setState({error: message});
|
return this.props.onShowChannelError(message);
|
||||||
![]() 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.setState({error: null}); // note: store this error at app level also
|
|
||||||
![]() 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.onChannelDataUpdate(data.channelName, data.longChannelClaimId, data.shortChannelClaimId);
|
this.props.onChannelDataUpdate(data.channelName, data.longChannelClaimId, data.shortChannelClaimId);
|
||||||
})
|
})
|
||||||
.catch((error) => {
|
.catch((error) => {
|
||||||
this.setState({error: error.message});
|
return this.props.onShowChannelError(error.message);
|
||||||
![]() 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.
|
|||||||
});
|
});
|
||||||
}
|
}
|
||||||
componentWillUnmount () {
|
componentWillUnmount () {
|
||||||
this.props.onChannelDataClear();
|
this.props.onChannelDataClear();
|
||||||
}
|
}
|
||||||
render () {
|
render () {
|
||||||
|
const { error, name, longId, shortId } = this.props;
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
|
if (error) {
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
|
return (
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
|
<ErrorPage error={error}/>
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
|
);
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
|
};
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
return (
|
return (
|
||||||
<div>
|
<div>
|
||||||
<NavBar/>
|
<NavBar/>
|
||||||
{this.state.error ? (
|
<div className="row row--tall row--padded">
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
<div className="row row--tall row--padded">
|
<div className="column column--10">
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
<div className="column column--10">
|
<h2>channel name: {name ? name : 'loading...'}</h2>
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
<p>{this.state.error}</p>
|
<p className={'fine-print'}>full channel id: {longId ? longId : 'loading...'}</p>
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
</div>
|
<p className={'fine-print'}>short channel id: {shortId ? shortId : 'loading...'}</p>
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
</div>
|
</div>
|
||||||
) : (
|
<div className="column column--10">
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
<div className="row row--tall row--padded">
|
{(name && longId) && <ChannelClaimsDisplay />}
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
<div className="column column--10">
|
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
<h2>channel name: {this.props.name ? this.props.name : 'loading...'}</h2>
|
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
<p className={'fine-print'}>full channel id: {this.props.longId ? this.props.longId : 'loading...'}</p>
|
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
<p className={'fine-print'}>short channel id: {this.props.shortId ? this.props.shortId : 'loading...'}</p>
|
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
</div>
|
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
<div className="column column--10">
|
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
{(this.props.name && this.props.longId) && <ChannelClaimsDisplay />}
|
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
</div>
|
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
</div>
|
</div>
|
||||||
)}
|
</div>
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|||||||
</div>
|
</div>
|
||||||
);
|
);
|
||||||
}
|
}
|
||||||
|
|
||||||
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
![]() Same comments above about
Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
![]() See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
|
@ -1,15 +1,19 @@
|
||||||
import { connect } from 'react-redux';
|
import { connect } from 'react-redux';
|
||||||
import { updateRequestWithChannelRequest, updateRequestWithAssetRequest } from 'actions/show';
|
import { updateRequestError, updateRequestWithChannelRequest, updateRequestWithAssetRequest } from 'actions/show';
|
||||||
import View from './view';
|
import View from './view';
|
||||||
|
|
||||||
const mapStateToProps = ({ show }) => {
|
const mapStateToProps = ({ show }) => {
|
||||||
return {
|
return {
|
||||||
|
error : show.request.error,
|
||||||
requestType: show.request.type,
|
requestType: show.request.type,
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
const mapDispatchToProps = dispatch => {
|
const mapDispatchToProps = dispatch => {
|
||||||
return {
|
return {
|
||||||
|
onRequestError: (error) => {
|
||||||
|
dispatch(updateRequestError(error));
|
||||||
|
},
|
||||||
onChannelRequest: (name, id) => {
|
onChannelRequest: (name, id) => {
|
||||||
dispatch(updateRequestWithChannelRequest(name, id));
|
dispatch(updateRequestWithChannelRequest(name, id));
|
||||||
},
|
},
|
||||||
|
|
|
@ -9,24 +9,17 @@ import { CHANNEL, ASSET } from 'constants/show_request_types';
|
||||||
class ShowPage extends React.Component {
|
class ShowPage extends React.Component {
|
||||||
constructor (props) {
|
constructor (props) {
|
||||||
super(props);
|
super(props);
|
||||||
this.state = {
|
|
||||||
error: null,
|
|
||||||
};
|
|
||||||
this.parseUrlAndUpdateState = this.parseUrlAndUpdateState.bind(this);
|
this.parseUrlAndUpdateState = this.parseUrlAndUpdateState.bind(this);
|
||||||
this.parseAndUpdateIdentifierAndClaim = this.parseAndUpdateIdentifierAndClaim.bind(this);
|
this.parseAndUpdateIdentifierAndClaim = this.parseAndUpdateIdentifierAndClaim.bind(this);
|
||||||
this.parseAndUpdateClaimOnly = this.parseAndUpdateClaimOnly.bind(this);
|
this.parseAndUpdateClaimOnly = this.parseAndUpdateClaimOnly.bind(this);
|
||||||
}
|
}
|
||||||
componentDidMount () {
|
componentDidMount () {
|
||||||
console.log('ShowPage did mount');
|
const { identifier, claim } = this.props.match.params;
|
||||||
const identifier = this.props.match.params.identifier;
|
|
||||||
const claim = this.props.match.params.claim;
|
|
||||||
this.parseUrlAndUpdateState(identifier, claim);
|
this.parseUrlAndUpdateState(identifier, claim);
|
||||||
}
|
}
|
||||||
componentWillReceiveProps (nextProps) {
|
componentWillReceiveProps (nextProps) {
|
||||||
if (nextProps.match.params !== this.props.match.params) {
|
if (nextProps.match.params !== this.props.match.params) {
|
||||||
console.log('ShowPage received new params props');
|
const { identifier, claim } = nextProps.match.params;
|
||||||
const identifier = nextProps.match.params.identifier;
|
|
||||||
const claim = nextProps.match.params.claim;
|
|
||||||
this.parseUrlAndUpdateState(identifier, claim);
|
this.parseUrlAndUpdateState(identifier, claim);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
@ -45,7 +38,7 @@ class ShowPage extends React.Component {
|
||||||
({ isChannel, channelName, channelClaimId, claimId } = lbryUri.parseIdentifier(modifier));
|
({ isChannel, channelName, channelClaimId, claimId } = lbryUri.parseIdentifier(modifier));
|
||||||
({ claimName, extension } = lbryUri.parseClaim(claim));
|
({ claimName, extension } = lbryUri.parseClaim(claim));
|
||||||
} catch (error) {
|
} catch (error) {
|
||||||
return this.setState({error: error.message});
|
return this.props.onRequestError(error.message);
|
||||||
}
|
}
|
||||||
// update the store
|
// update the store
|
||||||
if (isChannel) {
|
if (isChannel) {
|
||||||
|
@ -61,7 +54,7 @@ class ShowPage extends React.Component {
|
||||||
try {
|
try {
|
||||||
({ isChannel, channelName, channelClaimId } = lbryUri.parseIdentifier(claim));
|
({ isChannel, channelName, channelClaimId } = lbryUri.parseIdentifier(claim));
|
||||||
} catch (error) {
|
} catch (error) {
|
||||||
return this.setState({error: error.message});
|
return this.props.onRequestError(error.message);
|
||||||
}
|
}
|
||||||
// return early if this request is for a channel
|
// return early if this request is for a channel
|
||||||
if (isChannel) {
|
if (isChannel) {
|
||||||
|
@ -72,19 +65,18 @@ class ShowPage extends React.Component {
|
||||||
try {
|
try {
|
||||||
({claimName, extension} = lbryUri.parseClaim(claim));
|
({claimName, extension} = lbryUri.parseClaim(claim));
|
||||||
} catch (error) {
|
} catch (error) {
|
||||||
return this.setState({error: error.message});
|
return this.props.onRequestError(error.message);
|
||||||
}
|
}
|
||||||
this.props.onAssetRequest(claimName, null, null, null, extension);
|
this.props.onAssetRequest(claimName, null, null, null, extension);
|
||||||
}
|
}
|
||||||
render () {
|
render () {
|
||||||
console.log('rendering ShowPage');
|
const { error, requestType } = this.props;
|
||||||
console.log('ShowPage props', this.props);
|
if (error) {
|
||||||
if (this.state.error) {
|
|
||||||
return (
|
return (
|
||||||
<ErrorPage error={this.state.error}/>
|
<ErrorPage error={error}/>
|
||||||
);
|
);
|
||||||
}
|
}
|
||||||
switch (this.props.requestType) {
|
switch (requestType) {
|
||||||
case CHANNEL:
|
case CHANNEL:
|
||||||
return <ShowChannel />;
|
return <ShowChannel />;
|
||||||
case ASSET:
|
case ASSET:
|
||||||
|
|
|
@ -23,6 +23,7 @@ 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
|
|||||||
extension: null,
|
extension: null,
|
||||||
},
|
},
|
||||||
showChannel: {
|
showChannel: {
|
||||||
|
error : null,
|
||||||
![]() In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
![]() Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
![]() Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
|||||||
channelData: {
|
channelData: {
|
||||||
name : null,
|
name : null,
|
||||||
shortId: null,
|
shortId: null,
|
||||||
|
@ -52,23 +53,33 @@ Reducers describe how the application's state changes in response to actions
|
||||||
![]() 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
|
|||||||
|
|
||||||
export default function (state = initialState, action) {
|
export default function (state = initialState, action) {
|
||||||
switch (action.type) {
|
switch (action.type) {
|
||||||
case actions.REQUEST_CHANNEL_UPDATE:
|
// request cases
|
||||||
![]() 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.REQUEST_ERROR_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
|
|||||||
return Object.assign({}, state, {
|
return Object.assign({}, state, {
|
||||||
request: Object.assign({}, state.request, {
|
request: Object.assign({}, state.request, {
|
||||||
type: CHANNEL,
|
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
|
|||||||
|
case actions.REQUEST_CHANNEL_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
|
|||||||
|
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
|
|||||||
|
request: {
|
||||||
![]() 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
|
|||||||
|
type : 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
|
|||||||
|
error: null,
|
||||||
![]() In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
![]() Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
![]() Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
|||||||
|
},
|
||||||
![]() 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
|
|||||||
channelRequest: action.data,
|
channelRequest: action.data,
|
||||||
});
|
});
|
||||||
case actions.REQUEST_CLAIM_UPDATE:
|
case actions.REQUEST_CLAIM_UPDATE:
|
||||||
return Object.assign({}, state, {
|
return Object.assign({}, state, {
|
||||||
request: Object.assign({}, state.request, {
|
request: {
|
||||||
![]() 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
|
|||||||
type: ASSET,
|
type : ASSET,
|
||||||
![]() In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
![]() Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
![]() Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
![]() In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
![]() Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
![]() Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
|||||||
}),
|
error: null,
|
||||||
![]() In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
![]() Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
![]() Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
![]() 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: action.data,
|
assetRequest: action.data,
|
||||||
});
|
});
|
||||||
case actions.REQUEST_ERROR_UPDATE:
|
// show channel cases
|
||||||
![]() In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
![]() Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
![]() Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
![]() In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
![]() Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
![]() Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
|||||||
|
case actions.SHOW_CHANNEL_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
|
|||||||
return Object.assign({}, state, {
|
return Object.assign({}, state, {
|
||||||
request: Object.assign({}, state.request, {
|
showChannel: Object.assign({}, state.showAsset, {
|
||||||
![]() 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,
|
||||||
}),
|
}),
|
||||||
});
|
});
|
||||||
|
@ -84,6 +95,13 @@ 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
|
|||||||
channelClaimsData: action.data,
|
channelClaimsData: action.data,
|
||||||
}),
|
}),
|
||||||
});
|
});
|
||||||
|
// show asset cases
|
||||||
![]() In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
![]() Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
![]() Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
|||||||
|
case actions.SHOW_ASSET_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
|
|||||||
|
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
|
|||||||
|
showAsset: Object.assign({}, state.showAsset, {
|
||||||
![]() 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,
|
||||||
![]() 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.ASSET_CLAIM_DATA_UPDATE:
|
case actions.ASSET_CLAIM_DATA_UPDATE:
|
||||||
return Object.assign({}, state, {
|
return Object.assign({}, state, {
|
||||||
showAsset: Object.assign({}, state.showAsset, {
|
showAsset: Object.assign({}, state.showAsset, {
|
||||||
|
@ -91,12 +109,7 @@ 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
|
|||||||
shortId : action.data.shortId,
|
shortId : action.data.shortId,
|
||||||
}),
|
}),
|
||||||
});
|
});
|
||||||
case actions.SHOW_ASSET_ERROR:
|
// display asset cases
|
||||||
![]() 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
|
|||||||
showAsset: Object.assign({}, state.showAsset, {
|
|
||||||
![]() 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,
|
|
||||||
![]() 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.FILE_AVAILABILITY_UPDATE:
|
case actions.FILE_AVAILABILITY_UPDATE:
|
||||||
return Object.assign({}, state, {
|
return Object.assign({}, state, {
|
||||||
displayAsset: Object.assign({}, state.displayAsset, {
|
displayAsset: Object.assign({}, state.displayAsset, {
|
||||||
|
|
||||||
![]() 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
|
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