React router #343
|
|
@ -1,7 +1,7 @@
|
|||
I had a misunderstanding of how the I had a misunderstanding of how the `this` context works and when I needed to pass this in to a function manually. I was able to remove it from the app in multiple places where it isn't necessary.
Why do you do Why do you do `const that = this`?
I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same `<AssetDisplay />` it will make these requests again, even if you just made them a second ago
I had a misunderstanding of how the I had a misunderstanding of how the `this` context works and when I needed to pass this in to a function manually. I was able to remove it from the app in multiple places where it isn't necessary.
|
||||
import { connect } from 'react-redux';
|
||||
import View from './view';
|
||||
import { fileRequested } from 'actions/show';
|
||||
import selectAsset from 'selectors/asset';
|
||||
|
Why do you do Why do you do `const that = this`?
I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same `<AssetDisplay />` it will make these requests again, even if you just made them a second ago
I had a misunderstanding of how the I had a misunderstanding of how the `this` context works and when I needed to pass this in to a function manually. I was able to remove it from the app in multiple places where it isn't necessary.
|
||||
import { selectAsset } from 'selectors/show';
|
||||
|
Why do you do Why do you do `const that = this`?
I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same `<AssetDisplay />` it will make these requests again, even if you just made them a second ago
I had a misunderstanding of how the I had a misunderstanding of how the `this` context works and when I needed to pass this in to a function manually. I was able to remove it from the app in multiple places where it isn't necessary.
|
||||
|
||||
const mapStateToProps = ({ show }) => {
|
||||
// select error and status
|
||||
|
|
|
|||
|
Why do you do Why do you do `const that = this`?
I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same `<AssetDisplay />` it will make these requests again, even if you just made them a second ago
I had a misunderstanding of how the I had a misunderstanding of how the `this` context works and when I needed to pass this in to a function manually. I was able to remove it from the app in multiple places where it isn't necessary.
Why do you do Why do you do `const that = this`?
I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same `<AssetDisplay />` it will make these requests again, even if you just made them a second ago
I had a misunderstanding of how the I had a misunderstanding of how the `this` context works and when I needed to pass this in to a function manually. I was able to remove it from the app in multiple places where it isn't necessary.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
|
This should be a This should be a `button` if it isn't linking anywhere.
This should be a This should be a `button` if it isn't linking anywhere.
|
||||
import { connect } from 'react-redux';
|
||||
import View from './view';
|
||||
import selectAsset from 'selectors/asset';
|
||||
|
This should be a This should be a `button` if it isn't linking anywhere.
|
||||
import { selectAsset } from 'selectors/show';
|
||||
|
This should be a This should be a `button` if it isn't linking anywhere.
|
||||
|
||||
const mapStateToProps = ({ show }) => {
|
||||
// select asset
|
||||
|
|
|
|||
|
This should be a This should be a `button` if it isn't linking anywhere.
This should be a This should be a `button` if it isn't linking anywhere.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
import { connect } from 'react-redux';
|
||||
import View from './view';
|
||||
import selectAsset from 'selectors/asset';
|
||||
import { selectAsset } from 'selectors/show';
|
||||
|
||||
const mapStateToProps = ({ show }) => {
|
||||
// select title
|
||||
|
|
|
|||
|
|
@ -7,10 +7,10 @@ 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
|
||||
type : null,
|
||||
id : null,
|
||||
},
|
||||
requestList: {},
|
||||
|
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
|
||||
channelList : {},
|
||||
|
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
|
||||
assetList : {},
|
||||
|
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
|
||||
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
|
||||
requestList : {},
|
||||
|
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
|
||||
channelList : {},
|
||||
|
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
|
||||
assetList : {},
|
||||
|
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
|
||||
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
|
||||
error : null,
|
||||
status: LOCAL_CHECK,
|
||||
},
|
||||
|
|
|
|||
|
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
In the app we use a util to avoid a lot of the boiler plate with redux. It just makes it so you don't need to use a switch. I really like it. In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js
It just makes it so you don't need to use a switch. I really like it.
Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works. Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
Here is an example of it in the app Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
|
||||
|
|
@ -1,11 +1,19 @@
|
|||
import { call, put, takeLatest } from 'redux-saga/effects';
|
||||
import { call, put, select, takeLatest } from 'redux-saga/effects';
|
||||
import * as actions from 'constants/show_action_types';
|
||||
import { addRequestToRequestList, onRequestError, addAssetToAssetList } from 'actions/show';
|
||||
import { getLongClaimId, getShortId, getClaimData } from 'api/assetApi';
|
||||
import { selectShowState } from 'selectors/show';
|
||||
|
||||
function* newAssetRequest (action) {
|
||||
const { requestId, name, modifier } = action.data;
|
||||
// get long id
|
||||
const state = yield select(selectShowState);
|
||||
// is this an existing request?
|
||||
// If this uri is in the request list, it's already been fetched
|
||||
if (state.requestList[requestId]) {
|
||||
console.log('that request already exists in the request list!');
|
||||
return null;
|
||||
}
|
||||
// get long id && add request to request list
|
||||
console.log(`getting asset long id ${name}`);
|
||||
let longId;
|
||||
try {
|
||||
|
|
@ -14,9 +22,14 @@ function* newAssetRequest (action) {
|
|||
console.log('error:', error);
|
||||
return yield put(onRequestError(error.message));
|
||||
}
|
||||
// put action to add request to asset request list
|
||||
const assetKey = `a#${name}#${longId}`;
|
||||
yield put(addRequestToRequestList(requestId, null, assetKey));
|
||||
// is this an existing asset?
|
||||
// If this asset is in the asset list, it's already been fetched
|
||||
if (state.assetList[assetKey]) {
|
||||
console.log('that asset already exists in the asset list!');
|
||||
return null;
|
||||
}
|
||||
// get short Id
|
||||
console.log(`getting asset short id ${name} ${longId}`);
|
||||
let shortId;
|
||||
|
|
@ -33,7 +46,7 @@ function* newAssetRequest (action) {
|
|||
} catch (error) {
|
||||
return yield put(onRequestError(error.message));
|
||||
}
|
||||
// put action to add asset to asset list
|
||||
// add asset to asset list
|
||||
yield put(addAssetToAssetList(assetKey, null, name, longId, shortId, claimData));
|
||||
// clear any errors in request error
|
||||
yield put(onRequestError(null));
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
const selectAsset = (show) => {
|
||||
export const selectAsset = (show) => {
|
||||
const request = show.requestList[show.request.id];
|
||||
const assetKey = request.key;
|
||||
return show.assetList[assetKey];
|
||||
};
|
||||
|
||||
export default selectAsset;
|
||||
export const selectShowState = (state) => {
|
||||
return state.show;
|
||||
};
|
||||
Why do you do
const that = this?I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same
<AssetDisplay />it will make these requests again, even if you just made them a second ago