React router #343

Merged
bones7242 merged 96 commits from react-router into master 2018-02-15 08:02:17 +01:00
19 changed files with 368 additions and 326 deletions
Showing only changes of commit 2744045c5c - Show all commits

View file

@ -2,7 +2,7 @@ import * as actions from 'constants/show_action_types';
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

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_UPDATE_CHANNEL, type: actions.REQUEST_CHANNEL_UPDATE,
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
data: { data: {
name, name,
id, id,
@ -12,7 +12,7 @@ export function updateRequestWithChannelRequest (name, id) {
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
export function updateRequestWithAssetRequest (name, id, channelName, channelId, extension) { export function updateRequestWithAssetRequest (name, id, channelName, channelId, extension) {
return { return {
type: actions.REQUEST_UPDATE_CLAIM, type: actions.REQUEST_CLAIM_UPDATE,
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
data: { data: {
name, name,
modifier: { modifier: {
@ -27,6 +27,13 @@ export function updateRequestWithAssetRequest (name, id, channelName, channelId,
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
}; };
}; };
export function updateRequestError (error) {
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
return {
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
type: actions.REQUEST_ERROR_UPDATE,
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
data: error,
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
};
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
}
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

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 {
type: actions.CHANNEL_DATA_UPDATE, type: actions.CHANNEL_DATA_UPDATE,
@ -70,9 +77,9 @@ export function fileRequested (name, claimId) {
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
}; };
}; };
export function updateFileIsAvailable (status) { export function updateFileAvailability (status) {
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
return { return {
type: actions.FILE_IS_AVAILABLE_UPDATE, type: actions.FILE_AVAILABILITY_UPDATE,
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
data: status, data: status,
}; };
}; };
@ -83,3 +90,10 @@ export function updateShowAssetError (error) {
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
data: error, data: error,
}; };
}; };
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
export function updateDisplayAssetError (error) {
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
return {
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
type: actions.DISPLAY_ASSET_ERROR,
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
data: error,
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
};
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
};
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async

neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async
neb-b commented 2018-02-05 20:57:15 +01:00 (Migrated from github.com)
Review

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

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
neb-b commented 2018-02-13 06:05:56 +01:00 (Migrated from github.com)
Review

This probably shouldn't be called XXX_ASYNC since it isn't async

This probably shouldn't be called `XXX_ASYNC` since it isn't async

View file

@ -4,8 +4,8 @@ import { fileRequested } from 'actions/show';
neb-b commented 2018-02-05 20:47:37 +01:00 (Migrated from github.com)
Review

Why do you do const that = this?

Why do you do `const that = this`?
neb-b commented 2018-02-05 20:52:52 +01:00 (Migrated from github.com)
Review

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 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
bones7242 commented 2018-02-07 00:13:24 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-05 20:47:37 +01:00 (Migrated from github.com)
Review

Why do you do const that = this?

Why do you do `const that = this`?
neb-b commented 2018-02-05 20:52:52 +01:00 (Migrated from github.com)
Review

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 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
bones7242 commented 2018-02-07 00:13:24 +01:00 (Migrated from github.com)
Review

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.

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 }) => { const mapStateToProps = ({ show }) => {
return { return {
error : show.showAsset.error, error : show.displayAsset.error,
neb-b commented 2018-02-05 20:47:37 +01:00 (Migrated from github.com)
Review

Why do you do const that = this?

Why do you do `const that = this`?
neb-b commented 2018-02-05 20:52:52 +01:00 (Migrated from github.com)
Review

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 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
bones7242 commented 2018-02-07 00:13:24 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-05 20:47:37 +01:00 (Migrated from github.com)
Review

Why do you do const that = this?

Why do you do `const that = this`?
neb-b commented 2018-02-05 20:52:52 +01:00 (Migrated from github.com)
Review

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 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
bones7242 commented 2018-02-07 00:13:24 +01:00 (Migrated from github.com)
Review

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.

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.
status : show.showAsset.status, status : show.displayAsset.status,
neb-b commented 2018-02-05 20:47:37 +01:00 (Migrated from github.com)
Review

Why do you do const that = this?

Why do you do `const that = this`?
neb-b commented 2018-02-05 20:52:52 +01:00 (Migrated from github.com)
Review

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 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
bones7242 commented 2018-02-07 00:13:24 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-05 20:47:37 +01:00 (Migrated from github.com)
Review

Why do you do const that = this?

Why do you do `const that = this`?
neb-b commented 2018-02-05 20:52:52 +01:00 (Migrated from github.com)
Review

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 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
bones7242 commented 2018-02-07 00:13:24 +01:00 (Migrated from github.com)
Review

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.

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.
claimData: show.showAsset.claimData, claimData: show.showAsset.claimData,
}; };
}; };

View file

@ -1,5 +1,5 @@
import React from 'react'; import React from 'react';
import ProgressBar from 'components/ProgressBar/index'; import ProgressBar from 'components/ProgressBar';
import { LOCAL_CHECK, UNAVAILABLE, ERROR, AVAILABLE } from 'constants/asset_display_states'; import { LOCAL_CHECK, UNAVAILABLE, ERROR, AVAILABLE } from 'constants/asset_display_states';
class AssetDisplay extends React.Component { class AssetDisplay extends React.Component {
@ -7,9 +7,7 @@ class AssetDisplay extends React.Component {
this.props.onFileRequest(this.props.claimData.name, this.props.claimData.claimId); this.props.onFileRequest(this.props.claimData.name, this.props.claimData.claimId);
} }
render () { render () {
const status = this.props.status; const { status, error, claimData: { name, claimId, contentType, fileExt, thumbnail } } = this.props;
const error = this.props.error;
const { name, claimId, contentType, fileExt, thumbnail } = this.props.claimData;
return ( return (
<div id="asset-display-component"> <div id="asset-display-component">
{(status === LOCAL_CHECK) && {(status === LOCAL_CHECK) &&

View file

@ -1,179 +1,19 @@
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
import React from 'react'; import { connect } from 'react-redux';
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
import PropTypes from 'prop-types'; import View from './view';
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
import { Link } from 'react-router-dom';
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
class AssetInfo extends React.Component { const mapStateToProps = ({ show }) => {
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
constructor (props) { return {
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
super(props); shortId : show.showAsset.shortId,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
this.state = { channelName : show.showAsset.claimData.channelName,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
showDetails: false, certificateId: show.showAsset.claimData.certificateId,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
description : show.showAsset.claimData.description,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
name : show.showAsset.claimData.name,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
claimId : show.showAsset.claimData.claimId,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
fileExt : show.showAsset.claimData.fileExt,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
contentType : show.showAsset.claimData.contentType,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
thumbnail : show.showAsset.claimData.thumbnail,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
host : show.showAsset.claimData.host,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
}; };
this.toggleDetails = this.toggleDetails.bind(this);
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
this.copyToClipboard = this.copyToClipboard.bind(this);
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
toggleDetails () {
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
if (this.state.showDetails) {
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
return this.setState({showDetails: false});
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
this.setState({showDetails: true});
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
copyToClipboard (event) {
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
var elementToCopy = event.target.dataset.elementtocopy;
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
var element = document.getElementById(elementToCopy);
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
element.select();
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
try {
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
document.execCommand('copy');
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
} catch (err) {
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
this.setState({error: 'Oops, unable to copy'});
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
render () {
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
const { channelName, certificateId, description, name, claimId, fileExt, contentType, thumbnail, host, shortId } = this.props;
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
return (
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
{channelName &&
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="row row--padded row--wide row--no-top">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--2 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<span className="text">Channel:</span>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--8 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<span className="text"><a href={`/${channelName}:${certificateId}`}>{channelName}</a></span>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
{description &&
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="row row--padded row--wide row--no-top">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<span className="text">{description}</span>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="row row--padded row--wide row--no-top">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div id="show-short-link">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--2 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<Link className="link--primary" to={`/${shortId}/${name}.${fileExt}`}><span
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
className="text">Link:</span></Link>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--8 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="row row--short row--wide">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--7">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="input-error" id="input-error-copy-short-link" hidden="true">error here</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<input type="text" id="short-link" className="input-disabled input-text--full-width" readOnly
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
spellCheck="false"
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
value={`${host}/${shortId}/${name}.${fileExt}`}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
onClick={this.select}/>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--1"> </div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--2">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<button className="button--primary" data-elementtocopy="short-link"
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
onClick={this.copyToClipboard}>copy
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</button>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div id="show-embed-code">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--2 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<span className="text">Embed:</span>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--8 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="row row--short row--wide">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--7">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="input-error" id="input-error-copy-embed-text" hidden="true">error here</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
{(contentType === 'video/mp4') ? (
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<input type="text" id="embed-text" className="input-disabled input-text--full-width" readOnly
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
onClick={this.select} spellCheck="false"
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
value={`<video width="100%" controls poster="${thumbnail}" src="${host}/${claimId}/${name}.${fileExt}"/></video>`}/>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
) : (
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<input type="text" id="embed-text" className="input-disabled input-text--full-width" readOnly
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
onClick={this.select} spellCheck="false"
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
value={`<img src="${host}/${claimId}/${name}.${fileExt}"/>`}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
/>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
)}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--1"> </div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--2">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<button className="button--primary" data-elementtocopy="embed-text"
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
onClick={this.copyToClipboard}>copy
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</button>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div id="show-share-buttons">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="row row--padded row--wide row--no-top">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--2 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<span className="text">Share:</span>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--7 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
className="row row--short row--wide flex-container--row flex-container--space-between-bottom flex-container--wrap">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<a className="link--primary" target="_blank"
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
href={`https://twitter.com/intent/tweet?text=${host}/${shortId}/${name}`}>twitter</a>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<a className="link--primary" target="_blank"
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
href={`https://www.facebook.com/sharer/sharer.php?u=${host}/${shortId}/${name}`}>facebook</a>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<a className="link--primary" target="_blank"
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
href={`http://tumblr.com/widgets/share/tool?canonicalUrl=${host}/${shortId}/${name}`}>tumblr</a>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<a className="link--primary" target="_blank"
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
href={`https://www.reddit.com/submit?url=${host}/${shortId}/${name}&title=${name}`}>reddit</a>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
{ this.state.showDetails &&
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="row--padded row--wide row--no-top">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--2 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<span className="text">Claim Name:</span>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div><div className="column column--8 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
{name}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--2 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<span className="text">Claim Id:</span>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div><div className="column column--8 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
{claimId}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--2 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<span className="text">File Type:</span>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div><div className="column column--8 column--med-10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
{contentType ? `${contentType}` : 'unknown'}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="row--padded row--wide row--no-top">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="column column--10">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<a target="_blank" href="https://lbry.io/dmca">Report</a>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<div className="row row--wide">
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
<button className="button--secondary" onClick={this.toggleDetails}>{this.state.showDetails ? 'less' : 'more'}</button>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
</div>
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
);
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
}
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
}; };
AssetInfo.propTypes = { export default connect(mapStateToProps, null)(View);
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
channelName : PropTypes.string,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
certificateId: PropTypes.string,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
description : PropTypes.string,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
shortId : PropTypes.string.isRequired,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
name : PropTypes.string.isRequired,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
claimId : PropTypes.string.isRequired,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
contentType : PropTypes.string.isRequired,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
fileExt : PropTypes.string.isRequired,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
thumbnail : PropTypes.string,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
host : PropTypes.string.isRequired,
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
};
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
export default AssetInfo;
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.

neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.
neb-b commented 2018-02-05 20:39:44 +01:00 (Migrated from github.com)
Review

This should be a button if it isn't linking anywhere.

This should be a `button` if it isn't linking anywhere.

View file

@ -0,0 +1,165 @@
import React from 'react';
import { Link } from 'react-router-dom';
class AssetInfo extends React.Component {
constructor (props) {
super(props);
this.state = {
showDetails: false,
};
this.toggleDetails = this.toggleDetails.bind(this);
this.copyToClipboard = this.copyToClipboard.bind(this);
}
toggleDetails () {
if (this.state.showDetails) {
return this.setState({showDetails: false});
}
this.setState({showDetails: true});
}
copyToClipboard (event) {
var elementToCopy = event.target.dataset.elementtocopy;
var element = document.getElementById(elementToCopy);
element.select();
try {
document.execCommand('copy');
} catch (err) {
this.setState({error: 'Oops, unable to copy'});
}
}
render () {
const { shortId, channelName, certificateId, description, name, claimId, fileExt, contentType, thumbnail, host } = this.props;
return (
<div>
{channelName &&
<div className="row row--padded row--wide row--no-top">
<div className="column column--2 column--med-10">
<span className="text">Channel:</span>
</div>
<div className="column column--8 column--med-10">
<span className="text"><a href={`/${channelName}:${certificateId}`}>{channelName}</a></span>
</div>
</div>
}
{description &&
<div className="row row--padded row--wide row--no-top">
<span className="text">{description}</span>
</div>
}
<div className="row row--padded row--wide row--no-top">
<div id="show-short-link">
<div className="column column--2 column--med-10">
<Link className="link--primary" to={`/${shortId}/${name}.${fileExt}`}><span
className="text">Link:</span></Link>
</div>
<div className="column column--8 column--med-10">
<div className="row row--short row--wide">
<div className="column column--7">
<div className="input-error" id="input-error-copy-short-link" hidden="true">error here</div>
<input type="text" id="short-link" className="input-disabled input-text--full-width" readOnly
spellCheck="false"
value={`${host}/${shortId}/${name}.${fileExt}`}
onClick={this.select}/>
</div>
<div className="column column--1"> </div>
<div className="column column--2">
<button className="button--primary" data-elementtocopy="short-link"
onClick={this.copyToClipboard}>copy
</button>
</div>
</div>
</div>
</div>
<div id="show-embed-code">
<div className="column column--2 column--med-10">
<span className="text">Embed:</span>
</div>
<div className="column column--8 column--med-10">
<div className="row row--short row--wide">
<div className="column column--7">
<div className="input-error" id="input-error-copy-embed-text" hidden="true">error here</div>
{(contentType === 'video/mp4') ? (
<input type="text" id="embed-text" className="input-disabled input-text--full-width" readOnly
onClick={this.select} spellCheck="false"
value={`<video width="100%" controls poster="${thumbnail}" src="${host}/${claimId}/${name}.${fileExt}"/></video>`}/>
) : (
<input type="text" id="embed-text" className="input-disabled input-text--full-width" readOnly
onClick={this.select} spellCheck="false"
value={`<img src="${host}/${claimId}/${name}.${fileExt}"/>`}
/>
)}
</div>
<div className="column column--1"> </div>
<div className="column column--2">
<button className="button--primary" data-elementtocopy="embed-text"
onClick={this.copyToClipboard}>copy
</button>
</div>
</div>
</div>
</div>
</div>
<div id="show-share-buttons">
<div className="row row--padded row--wide row--no-top">
<div className="column column--2 column--med-10">
<span className="text">Share:</span>
</div>
<div className="column column--7 column--med-10">
<div
className="row row--short row--wide flex-container--row flex-container--space-between-bottom flex-container--wrap">
<a className="link--primary" target="_blank"
href={`https://twitter.com/intent/tweet?text=${host}/${shortId}/${name}`}>twitter</a>
<a className="link--primary" target="_blank"
href={`https://www.facebook.com/sharer/sharer.php?u=${host}/${shortId}/${name}`}>facebook</a>
<a className="link--primary" target="_blank"
href={`http://tumblr.com/widgets/share/tool?canonicalUrl=${host}/${shortId}/${name}`}>tumblr</a>
<a className="link--primary" target="_blank"
href={`https://www.reddit.com/submit?url=${host}/${shortId}/${name}&title=${name}`}>reddit</a>
</div>
</div>
</div>
</div>
{ this.state.showDetails &&
<div>
<div className="row--padded row--wide row--no-top">
<div>
<div className="column column--2 column--med-10">
<span className="text">Claim Name:</span>
</div><div className="column column--8 column--med-10">
{name}
</div>
</div>
<div>
<div className="column column--2 column--med-10">
<span className="text">Claim Id:</span>
</div><div className="column column--8 column--med-10">
{claimId}
</div>
</div>
<div>
<div className="column column--2 column--med-10">
<span className="text">File Type:</span>
</div><div className="column column--8 column--med-10">
{contentType ? `${contentType}` : 'unknown'}
</div>
</div>
</div>
<div className="row--padded row--wide row--no-top">
<div className="column column--10">
<a target="_blank" href="https://lbry.io/dmca">Report</a>
</div>
</div>
</div>
}
<div className="row row--wide">
<button className="button--secondary" onClick={this.toggleDetails}>{this.state.showDetails ? 'less' : 'more'}</button>
</div>
</div>
);
}
};
export default AssetInfo;

View file

@ -1,11 +1,10 @@
import React from 'react'; import { connect } from 'react-redux';
import View from './view';
const AssetTitle = ({title}) => { const mapStateToProps = ({ show }) => {
return ( return {
<div> title: show.showAsset.claimData.title,
<span className="text--large">{title}</span> };
</div>
);
}; };
export default AssetTitle; export default connect(mapStateToProps, null)(View);

View file

@ -0,0 +1,11 @@
import React from 'react';
const AssetTitle = ({title}) => {
return (
<div>
<span className="text--large">{title}</span>
</div>
);
};
export default AssetTitle;

View file

@ -1,57 +1,10 @@
import React from 'react'; import { connect } from 'react-redux';
import PropTypes from 'prop-types'; import View from './view';
import NavBar from 'containers/NavBar';
import AssetTitle from 'components/AssetTitle';
import AssetDisplay from 'containers/AssetDisplay';
import AssetInfo from 'components/AssetInfo';
class ShowAssetDetails extends React.Component { const mapStateToProps = ({ show }) => {
render () { return {
const { error, claimData: { title, channelName, certificateId, description, name, claimId, fileExt, contentType, thumbnail, host }, shortId } = this.props; claimData: show.showAsset.claimData,
return ( };
<div>
<NavBar/>
{error &&
<div className="row row--padded">
<p>{error}</p>
</div>
}
{this.props.claimData &&
<div className="row row--tall row--padded">
<div className="column column--10">
<AssetTitle title={title}/>
</div>
<div className="column column--5 column--sml-10 align-content-top">
<div className="row row--padded">
<AssetDisplay />
</div>
</div><div className="column column--5 column--sml-10 align-content-top">
<div className="row row--padded">
<AssetInfo
channelName={channelName}
certificateId={certificateId}
description={description}
name={name}
claimId={claimId}
fileExt={fileExt}
contentType={contentType}
thumbnail={thumbnail}
host={host}
shortId={shortId}
/>
</div>
</div>
</div>
}
</div>
);
}
}; };
ShowAssetDetails.propTypes = { export default connect(mapStateToProps, null)(View);
error : PropTypes.string,
claimData: PropTypes.object.isRequired,
shortId : PropTypes.string.isRequired,
};
export default ShowAssetDetails;

View file

@ -0,0 +1,39 @@
import React from 'react';
import PropTypes from 'prop-types';
import NavBar from 'containers/NavBar';
import AssetTitle from 'components/AssetTitle';
import AssetDisplay from 'components/AssetDisplay';
import AssetInfo from 'components/AssetInfo';
class ShowAssetDetails extends React.Component {
render () {
const { claimData } = this.props;
return (
<div>
<NavBar/>
{claimData &&
<div className="row row--tall row--padded">
<div className="column column--10">
<AssetTitle />
</div>
<div className="column column--5 column--sml-10 align-content-top">
<div className="row row--padded">
<AssetDisplay />
</div>
</div><div className="column column--5 column--sml-10 align-content-top">
<div className="row row--padded">
<AssetInfo />
</div>
</div>
</div>
}
</div>
);
}
};
ShowAssetDetails.propTypes = {
error: PropTypes.string,
};
export default ShowAssetDetails;

View file

@ -1,30 +1,11 @@
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
import React from 'react'; import { connect } from 'react-redux';
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
import PropTypes from 'prop-types'; import View from './view';
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
import { Link } from 'react-router-dom';
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
import AssetDisplay from 'containers/AssetDisplay';
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
class ShowLite extends React.Component { const mapStateToProps = ({ show }) => {
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
render () { return {
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
const { error, claimData: { name, claimId } } = this.props; name : show.showAsset.claimData.name,
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
return ( claimId: show.showAsset.claimData.claimId,
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
<div className="row row--tall flex-container--column flex-container--center-center"> };
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
{error &&
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
<p>{error}</p>
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
}
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
{this.props.claimData &&
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
<div>
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
<AssetDisplay />
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
<Link id="asset-boilerpate" className="link--primary fine-print" to={`/${claimId}/${name}`}>hosted via Spee.ch</Link>
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
</div>
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
}
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
</div>
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
);
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
}
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
}; };
ShowLite.propTypes = { export default connect(mapStateToProps, null)(View);
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
error : PropTypes.string,
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
claimData: PropTypes.object.isRequired,
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
};
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
export default ShowLite;
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`

neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
neb-b commented 2018-02-05 20:34:53 +01:00 (Migrated from github.com)
Review

You can use destructuring twice to avoid all the repeated this.props.claimData

const { claimData: { name, claimId... } } = this.props

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`

View file

@ -0,0 +1,21 @@
import React from 'react';
import { Link } from 'react-router-dom';
import AssetDisplay from 'components/AssetDisplay';
class ShowLite extends React.Component {
render () {
const { name, claimId } = this.props;
return (
<div className="row row--tall flex-container--column flex-container--center-center">
{ (name && claimId) &&
<div>
<AssetDisplay />
<Link id="asset-boilerpate" className="link--primary fine-print" to={`/${claimId}/${name}`}>hosted via Spee.ch</Link>
</div>
}
</div>
);
}
};
export default ShowLite;

View file

@ -1,8 +1,10 @@
export const REQUEST_UPDATE_CHANNEL = 'REQUEST_UPDATE_CHANNEL'; export const REQUEST_CHANNEL_UPDATE = 'REQUEST_CHANNEL_UPDATE';
export const REQUEST_UPDATE_CLAIM = 'REQUEST_UPDATE_CLAIM'; export const REQUEST_CLAIM_UPDATE = 'REQUEST_CLAIM_UPDATE';
export const REQUEST_ERROR_UPDATE = 'REQUEST_ERROR_UPDATE';
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 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_IS_AVAILABLE_UPDATE = 'FILE_IS_AVAILABLE_UPDATE'; export const FILE_AVAILABILITY_UPDATE = 'FILE_AVAILABILITY_UPDATE';
export const SHOW_ASSET_ERROR = 'SHOW_ASSET_ERROR'; export const SHOW_ASSET_ERROR = 'SHOW_ASSET_ERROR';
export const DISPLAY_ASSET_ERROR = 'DISPLAY_ASSET_ERROR';

View file

@ -1,5 +1,5 @@
neb-b commented 2018-02-05 20:26:45 +01:00 (Migrated from github.com)
Review

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch updateClaimsData action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
neb-b commented 2018-02-05 20:26:45 +01:00 (Migrated from github.com)
Review

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch updateClaimsData action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
import React from 'react/index'; import React from 'react';
neb-b commented 2018-02-05 20:26:45 +01:00 (Migrated from github.com)
Review

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch updateClaimsData action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
neb-b commented 2018-02-05 20:26:45 +01:00 (Migrated from github.com)
Review

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch updateClaimsData action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
import AssetPreview from 'components/AssetPreview/index'; import AssetPreview from 'components/AssetPreview';
neb-b commented 2018-02-05 20:26:45 +01:00 (Migrated from github.com)
Review

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch updateClaimsData action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
neb-b commented 2018-02-05 20:26:45 +01:00 (Migrated from github.com)
Review

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch updateClaimsData action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
import request from 'utils/request'; import request from 'utils/request';
class ChannelClaimsDisplay extends React.Component { class ChannelClaimsDisplay extends React.Component {

neb-b commented 2018-02-05 20:26:45 +01:00 (Migrated from github.com)
Review

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch updateClaimsData action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)
neb-b commented 2018-02-05 20:26:45 +01:00 (Migrated from github.com)
Review

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch updateClaimsData action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)

This might be what you were thinking of doing, but instead of doing the request here, then calling an action to update the data or set an error, just dispatch `updateClaimsData` action which makes the call, then updates the redux state accordingly. I think making an effort to keep all data logic inside of redux files can simplify a lot of components (for the most part)

View file

@ -1,24 +1,29 @@
import { connect } from 'react-redux'; import { connect } from 'react-redux';
import View from './view'; import View from './view';
import { updateAssetClaimData } from 'actions/show'; import { updateAssetClaimData, updateShowAssetError } from 'actions/show';
const mapStateToProps = ({ show }) => { const mapStateToProps = ({ show }) => {
return { return {
modifier : show.assetRequest.modifier, modifier : show.assetRequest.modifier,
claim : show.assetRequest.name, name : show.assetRequest.name,
extension: show.assetRequest.extension, extension: show.assetRequest.extension,
error : show.showAsset.error,
claimData: show.showAsset.claimData, claimData: show.showAsset.claimData,
shortId : show.showAsset.shortId,
}; };
}; };
const mapDispatchToProps = dispatch => { const mapDispatchToProps = dispatch => {
return { return {
onShowAssetError: (error) => {
dispatch(updateShowAssetError(error));
},
onAssetClaimDataUpdate: (claimData, shortId) => { onAssetClaimDataUpdate: (claimData, shortId) => {
dispatch(updateAssetClaimData(claimData, shortId)); dispatch(updateAssetClaimData(claimData, shortId));
dispatch(updateShowAssetError(null)); // clear any errors
}, },
onAssetClaimDataClear: () => { onAssetClaimDataClear: () => {
dispatch(updateAssetClaimData(null, null)); dispatch(updateAssetClaimData(null, null));
dispatch(updateShowAssetError(null)); // clear any errors
}, },
}; };
}; };

View file

@ -6,17 +6,11 @@ import request from 'utils/request';
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
class ShowAsset extends React.Component { class ShowAsset extends React.Component {
constructor (props) { constructor (props) {
super(props); super(props);
this.state = {
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
error: null,
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
};
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.getLongClaimId = this.getLongClaimId.bind(this); this.getLongClaimId = this.getLongClaimId.bind(this);
this.getClaimData = this.getClaimData.bind(this); this.getClaimData = this.getClaimData.bind(this);
} }
componentDidMount () { componentDidMount () {
console.log('ShowAsset did mount'); const { name, modifier } = this.props;
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

Ok, I think I'm getting closer. I was able to do away with `onShowNewAsset` and combine the needed logic from its action (retrieving the asset's claim data) into `onNewRequest`. That allowed me to remove `previousRequest` from the props I am passing to the `<ShowAsset />` component. However, I am still checking for a `previousRequest` in the mapStateToProps function. Do you see a way to avoid that step altogether? The reason for storing and checking the previous requests is to avoid having to retrieve new information for a request that was already made (i.e. to avoid having to request the full `claimId` from the server). I'm trying to figure out if that can be skipped or consolidated, but I am not sure how.
console.log('ShowAsset props', this.props);
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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 modifier = this.props.modifier;
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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 name = this.props.claim;
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
// create request params // create request params
let body = {}; let body = {};
if (modifier) { if (modifier) {
@ -41,11 +35,10 @@ class ShowAsset extends React.Component {
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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 Promise.all([this.getShortClaimId(claimLongId, name), this.getClaimData(claimLongId, name)]); return Promise.all([this.getShortClaimId(claimLongId, name), this.getClaimData(claimLongId, name)]);
}) })
.then(([shortId, claimData]) => { .then(([shortId, claimData]) => {
this.setState({error: null}); // note: move this to redux level
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.onAssetClaimDataUpdate(claimData, shortId); this.props.onAssetClaimDataUpdate(claimData, shortId);
}) })
.catch(error => { .catch(error => {
this.setState({error}); this.props.onShowAssetError(error);
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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) {
@ -101,26 +94,25 @@ class ShowAsset extends React.Component {
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.onAssetClaimDataClear(); this.props.onAssetClaimDataClear();
} }
render () { render () {
if (this.props.claimData) { const { error, claimData, extension } = this.props;
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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 (this.props.extension) { if (error) {
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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 ( return (
<ShowAssetLite <p>{error}</p>
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
error={this.state.error} );
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
claimData={this.props.claimData} }
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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) {
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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 (extension) {
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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 (
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
<ShowAssetLite />
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
); );
} else { } else {
return ( return (
<ShowAssetDetails <ShowAssetDetails />
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
error={this.state.error}
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
claimData={this.props.claimData}
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
shortId={this.props.shortId}
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
/>
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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 ( return (
<div></div> <div> </div>
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
); );
} }
}; };

neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.
neb-b commented 2018-02-13 06:13:36 +01:00 (Migrated from github.com)
Review

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".

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".
bones7242 commented 2018-02-14 02:17:20 +01:00 (Migrated from github.com)
Review

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.

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.

View file

@ -4,7 +4,7 @@ import View from './view';
const mapStateToProps = ({ show }) => { const mapStateToProps = ({ show }) => {
return { return {
requestType: show.requestType, requestType: show.request.type,
}; };
}; };

View file

@ -3,7 +3,10 @@ import { CHANNEL, ASSET } from 'constants/show_request_types';
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
import { LOCAL_CHECK, ERROR } from 'constants/asset_display_states'; import { LOCAL_CHECK, ERROR } from 'constants/asset_display_states';
const initialState = { const initialState = {
requestType : null, request: {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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,
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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,
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
},
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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: { channelRequest: {
name: null, name: null,
id : null, id : null,
@ -34,10 +37,13 @@ const initialState = {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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: { showAsset: {
error : null, error : null,
status : LOCAL_CHECK,
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
claimData: null, claimData: null,
shortId : null, shortId : null,
}, },
displayAsset: {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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,
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
status: LOCAL_CHECK,
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
},
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
}; };
/* /*
@ -46,16 +52,26 @@ Reducers describe how the application's state changes in response to actions
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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_UPDATE_CHANNEL: case actions.REQUEST_CHANNEL_UPDATE:
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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, {
requestType : CHANNEL, request: Object.assign({}, state.request, {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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,
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
}),
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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_UPDATE_CLAIM: case actions.REQUEST_CLAIM_UPDATE:
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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, {
requestType : ASSET, request: Object.assign({}, state.request, {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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,
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
}),
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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:
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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, {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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: Object.assign({}, state.request, {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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,
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
}),
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
});
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
Here is an example of it in the app https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
case actions.CHANNEL_DATA_UPDATE: case actions.CHANNEL_DATA_UPDATE:
return Object.assign({}, state, { return Object.assign({}, state, {
showChannel: Object.assign({}, state.showChannel, { showChannel: Object.assign({}, state.showChannel, {
@ -75,15 +91,21 @@ export default function (state = initialState, action) {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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.FILE_IS_AVAILABLE_UPDATE:
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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, {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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, {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
status: action.data,
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
}),
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
});
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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: case actions.SHOW_ASSET_ERROR:
return Object.assign({}, state, { return Object.assign({}, state, {
showAsset: Object.assign({}, state.showAsset, { showAsset: Object.assign({}, state.showAsset, {
error: action.data,
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
}),
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
});
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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:
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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, {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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: Object.assign({}, state.displayAsset, {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
status: action.data,
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
}),
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
});
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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.DISPLAY_ASSET_ERROR:
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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, {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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: Object.assign({}, state.displayAsset, {
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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,
status: ERROR, status: ERROR,
}), }),

neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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
neb-b commented 2018-02-05 20:12:41 +01:00 (Migrated from github.com)
Review

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.

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.
bones7242 commented 2018-02-09 20:29:01 +01:00 (Migrated from github.com)
Review

Hmm, I like the readability 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.
neb-b commented 2018-02-09 20:57:10 +01:00 (Migrated from github.com)
Review
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

View file

@ -1,6 +1,6 @@
import { call, put, takeLatest } from 'redux-saga/effects'; import { call, put, takeLatest } from 'redux-saga/effects';
import * as actions from 'constants/show_action_types'; import * as actions from 'constants/show_action_types';
import { updateFileIsAvailable, updateShowAssetError } from 'actions/show'; import { updateFileAvailability, updateDisplayAssetError } from 'actions/show';
import { UNAVAILABLE, AVAILABLE } from 'constants/asset_display_states'; import { UNAVAILABLE, AVAILABLE } from 'constants/asset_display_states';
import { checkFileAvailability, triggerClaimGet } from 'api/fileApi'; import { checkFileAvailability, triggerClaimGet } from 'api/fileApi';
@ -12,27 +12,27 @@ function* retriveFile (action) {
try { try {
({ success, message, data: isAvailable } = yield call(checkFileAvailability, name, claimId)); ({ success, message, data: isAvailable } = yield call(checkFileAvailability, name, claimId));
} catch (error) { } catch (error) {
return yield put(updateShowAssetError(error.message)); return yield put(updateDisplayAssetError(error.message));
}; };
if (success) { if (success) {
if (isAvailable) { if (isAvailable) {
return yield put(updateFileIsAvailable(AVAILABLE)); return yield put(updateFileAvailability(AVAILABLE));
} }
yield put(updateFileIsAvailable(UNAVAILABLE)); yield put(updateFileAvailability(UNAVAILABLE));
} else { } else {
yield put(updateShowAssetError(message)); yield put(updateDisplayAssetError(message));
} }
// initiate get request for the file // initiate get request for the file
try { try {
({ success, message } = yield call(triggerClaimGet, name, claimId)); ({ success, message } = yield call(triggerClaimGet, name, claimId));
} catch (error) { } catch (error) {
return yield put(updateShowAssetError(error.message)); return yield put(updateDisplayAssetError(error.message));
}; };
if (success) { if (success) {
console.log('/api/glaim-get response:', message); console.log('/api/glaim-get response:', message);
yield put(updateFileIsAvailable(AVAILABLE)); yield put(updateFileAvailability(AVAILABLE));
} else { } else {
yield put(updateShowAssetError(message)); yield put(updateDisplayAssetError(message));
} }
} }

View file

@ -207,7 +207,7 @@ module.exports = (app) => {
res.status(200).json({success: false, message: error.message}); res.status(200).json({success: false, message: error.message});
}); });
}); });
app.post('/api/claim/long-id', ({ ip, originalUrl, body, params }, res) => { app.get('/api/claim/long-id', ({ ip, originalUrl, body, params }, res) => {
logger.debug('body:', body); logger.debug('body:', body);
const channelName = body.channelName; const channelName = body.channelName;
const channelClaimId = body.channelClaimId; const channelClaimId = body.channelClaimId;