React router #343
|
|
@ -53,7 +53,8 @@ export function addAssetRequest (id, error, name, claimId) {
|
|||
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
|
||||
// show an asset
|
||||
|
||||
export function showNewAsset (id, name, claimId) {
|
||||
|
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
export function showNewAsset (name, claimId) {
|
||||
|
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
const id = `a#${name}#${claimId}`;
|
||||
|
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
return {
|
||||
type: actions.SHOW_ASSET_NEW,
|
||||
data: { id, name, claimId },
|
||||
|
|
@ -100,7 +101,8 @@ export function addChannelRequest (id, error, name, longId, shortId) {
|
|||
|
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
|
||||
// show a channel
|
||||
|
||||
export function showNewChannel (id, channelData) {
|
||||
|
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 showNewChannel (channelData) {
|
||||
|
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
|
||||
const id = `c#${channelData.name}#${channelData.longId}`; // move to the action
|
||||
|
I think generally the pattern is that an action is I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
This probably shouldn't be called This probably shouldn't be called `XXX_ASYNC` since it isn't async
|
||||
return {
|
||||
type: actions.SHOW_CHANNEL_NEW,
|
||||
data: { id, channelData },
|
||||
|
|
|
|||
|
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
|
||||
|
|
@ -27,8 +27,8 @@ const mapDispatchToProps = dispatch => {
|
|||
onRequestError: (error) => {
|
||||
dispatch(updateRequestError(error, null, null));
|
||||
},
|
||||
onShowNewAsset: (id, name, claimId) => {
|
||||
dispatch(showNewAsset(id, name, claimId));
|
||||
onShowNewAsset: (name, claimId) => {
|
||||
dispatch(showNewAsset(name, claimId));
|
||||
},
|
||||
onShowExistingAsset: (error, name, claimId, shortId, claimData) => {
|
||||
dispatch(updateShowAsset(error, name, claimId, shortId, claimData));
|
||||
|
|
|
|||
|
|
@ -54,11 +54,11 @@ 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.
|
||||
if (existingAssetRecord) { // case: the asset data already exists
|
||||
this.showExistingAsset(existingAssetRecord);
|
||||
} else { // case: the asset data does not exist yet
|
||||
this.showNewAsset(assetId, name, claimId);
|
||||
|
I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
|
||||
this.showNewAsset(name, claimId);
|
||||
|
I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
|
||||
}
|
||||
}
|
||||
showNewAsset (assetId, name, claimId) {
|
||||
|
I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
|
||||
this.props.onShowNewAsset(assetId, name, claimId);
|
||||
|
I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
|
||||
showNewAsset (name, claimId) {
|
||||
|
I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
|
||||
this.props.onShowNewAsset(name, claimId);
|
||||
|
I think you are still creating more work than necessary with this. In my opinion I also think I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request.
I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
Ok, I think I'm getting closer. I was able to do away with Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
|
||||
}
|
||||
showExistingAsset (existingAssetRecord) {
|
||||
let { error, name, claimId, shortId, claimData } = existingAssetRecord;
|
||||
|
|
|
|||
|
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.
|
||||
|
|
@ -27,8 +27,8 @@ const mapDispatchToProps = dispatch => {
|
|||
onRequestError: (error) => {
|
||||
dispatch(updateRequestError(error, null, null));
|
||||
},
|
||||
onShowNewChannel: (id, channelData) => {
|
||||
dispatch(showNewChannel(id, channelData));
|
||||
onShowNewChannel: (channelData) => {
|
||||
dispatch(showNewChannel(channelData));
|
||||
},
|
||||
onShowExistingChannel: (error, name, shortId, longId, claimsData) => {
|
||||
dispatch(updateShowChannel(error, name, shortId, longId, claimsData));
|
||||
|
|
|
|||
|
|
@ -51,19 +51,17 @@ 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.
|
||||
if (existingChannel) {
|
||||
this.showExistingChannel(existingChannel);
|
||||
} else {
|
||||
this.showNewChannel(channelRecordId, channelData);
|
||||
|
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.showNewChannel(channelData);
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
}
|
||||
}
|
||||
showNewChannel (channelRecordId, channelData) {
|
||||
|
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.onShowNewChannel(channelRecordId, channelData);
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
showNewChannel (channelData) {
|
||||
|
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.onShowNewChannel(channelData);
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
};
|
||||
showExistingChannel (existingChannel) {
|
||||
console.log('showExistingChannel:', existingChannel);
|
||||
|
Same comments above about Same comments above about `previousRequest`. I think a more understandable approach would just be:
```
if (!channel) this.props.onNewChannelRequest(...)
```
See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done. See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
|
||||
const { error, channelData: {name, shortId, longId}, claimsData } = existingChannel;
|
||||
this.props.onShowExistingChannel(error, name, shortId, longId, claimsData);
|
||||
};
|
||||
componentWillUnmount () {
|
||||
console.log('ShowChannel will unmount');
|
||||
|
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.onShowChannelClear();
|
||||
}
|
||||
render () {
|
||||
|
|
|
|||
|
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.
|
||||
|
|
@ -12,30 +12,25 @@ function* newAssetRequest (action) {
|
|||
try {
|
||||
({success, message, data: longId} = yield call(getLongClaimId, name, modifier));
|
||||
} catch (error) {
|
||||
// yield put(addAssetRequest(id, error.message, name, null));
|
||||
return yield put(updateRequestError(error.message));
|
||||
}
|
||||
if (!success) {
|
||||
// yield put(addAssetRequest(id, message, name, null));
|
||||
return yield put(updateRequestError(message));
|
||||
}
|
||||
yield put(addAssetRequest(id, null, name, longId));
|
||||
const newAssetId = `a#${name}#${longId}`; // note: move to action
|
||||
yield put(showNewAsset(newAssetId, name, longId));
|
||||
yield put(showNewAsset(name, longId));
|
||||
};
|
||||
|
||||
function* getAssetDataAndShowAsset (action) {
|
||||
const {id, name, claimId} = action.data;
|
||||
// if no error, get short Id
|
||||
// get short Id
|
||||
let success, message, shortId;
|
||||
try {
|
||||
({success, message, data: shortId} = yield call(getShortId, name, claimId));
|
||||
} catch (error) {
|
||||
// yield put(addAssetToAssetList());
|
||||
return yield put(updateShowAsset(error.message, name, claimId));
|
||||
}
|
||||
if (!success) {
|
||||
// yield put(addAssetToAssetList());
|
||||
return yield put(updateShowAsset(message, name, claimId));
|
||||
}
|
||||
// if no error, get claim data
|
||||
|
|
@ -44,14 +39,11 @@ function* getAssetDataAndShowAsset (action) {
|
|||
try {
|
||||
({success, message, data: claimData} = yield call(getClaimData, name, claimId));
|
||||
} catch (error) {
|
||||
// yield put(addAssetToAssetList());
|
||||
return yield put(updateShowAsset(error.message, name, claimId));
|
||||
}
|
||||
if (!success) {
|
||||
// yield put(addAssetToAssetList());
|
||||
return yield put(updateShowAsset(message, name, claimId));
|
||||
}
|
||||
// if both are successfull, add to asset list and select for showing
|
||||
yield put(updateShowAsset(null, name, claimId, shortId, claimData));
|
||||
yield put(addAssetToAssetList(id, null, name, claimId, shortId, claimData));
|
||||
}
|
||||
|
|
@ -66,26 +58,23 @@ function* retrieveFile (action) {
|
|||
} catch (error) {
|
||||
return yield put(updateDisplayAssetError(error.message));
|
||||
};
|
||||
if (success) {
|
||||
if (isAvailable) {
|
||||
return yield put(updateFileAvailability(AVAILABLE));
|
||||
}
|
||||
yield put(updateFileAvailability(UNAVAILABLE));
|
||||
} else {
|
||||
yield put(updateDisplayAssetError(message));
|
||||
if (!success) {
|
||||
return yield put(updateDisplayAssetError(message));
|
||||
}
|
||||
if (isAvailable) {
|
||||
return yield put(updateFileAvailability(AVAILABLE));
|
||||
}
|
||||
yield put(updateFileAvailability(UNAVAILABLE));
|
||||
// initiate get request for the file
|
||||
try {
|
||||
({ success, message } = yield call(triggerClaimGet, name, claimId));
|
||||
} catch (error) {
|
||||
return yield put(updateDisplayAssetError(error.message));
|
||||
};
|
||||
if (success) {
|
||||
console.log('/api/glaim-get response:', message);
|
||||
yield put(updateFileAvailability(AVAILABLE));
|
||||
} else {
|
||||
yield put(updateDisplayAssetError(message));
|
||||
if (!success) {
|
||||
return yield put(updateDisplayAssetError(message));
|
||||
}
|
||||
yield put(updateFileAvailability(AVAILABLE));
|
||||
};
|
||||
|
||||
function* newChannelRequest (action) {
|
||||
|
|
@ -103,9 +92,8 @@ function* newChannelRequest (action) {
|
|||
}
|
||||
const { longChannelClaimId: longId, shortChannelClaimId: shortId } = data;
|
||||
yield put(addChannelRequest(id, null, name, longId, shortId));
|
||||
const channelRecordId = `c#${name}#${longId}`; // move to the action
|
||||
const channelData = {name, longId, shortId};
|
||||
yield put(showNewChannel(channelRecordId, channelData));
|
||||
yield put(showNewChannel(channelData));
|
||||
}
|
||||
|
||||
function* getNewChannelDataAndShowChannel (action) {
|
||||
|
|
@ -114,11 +102,9 @@ function* getNewChannelDataAndShowChannel (action) {
|
|||
try {
|
||||
({ success, message, data: claimsData } = yield call(getChannelClaims, name, longId, 1));
|
||||
} catch (error) {
|
||||
// yield put(addNewChannelToChannelList(id, error.message, null, null));
|
||||
return yield put(updateShowChannel(error.message, name, shortId, longId));
|
||||
}
|
||||
if (!success) {
|
||||
// yield put(addNewChannelToChannelList(id, message, null, null));
|
||||
return yield put(updateShowChannel(message, name, shortId, longId));
|
||||
}
|
||||
yield put(updateShowChannel(null, name, shortId, longId, claimsData));
|
||||
|
|
|
|||
I think generally the pattern is that an action is
{ type: "some string", data: { name, id... } }just to keep things consistent.datacan be an object or a string, but I think it's helpful to put everything inside of that