Comment Styling #2510

Merged
NetOpWibby merged 11 commits from redux-comments into master 2019-06-27 02:32:44 +02:00
23 changed files with 350 additions and 92 deletions

View file

@ -46,7 +46,8 @@
"electron-log": "^2.2.12",
"electron-updater": "^4.0.6",
"express": "^4.16.4",
"keytar": "^4.4.1"
"keytar": "^4.4.1",
"tiny-relative-date": "^1.3.0"
},
"devDependencies": {
"@babel/core": "^7.0.0",
@ -122,7 +123,7 @@
"jsmediatags": "^3.8.1",
"json-loader": "^0.5.4",
"lbry-format": "https://github.com/lbryio/lbry-format.git",
"lbry-redux": "lbryio/lbry-redux#3c862e72b36e620155b9c968be9b2bcbd9e0580c",
"lbry-redux": "lbryio/lbry-redux#141593500693a93db74c62ef5a9fe67b43896603",
"lbryinc": "lbryio/lbryinc#43d382d9b74d396a581a74d87e4c53105e04f845",
"lint-staged": "^7.0.2",
"localforage": "^1.7.1",
@ -148,7 +149,7 @@
"react-dom": "^16.8.2",
"react-feather": "^1.0.8",
"react-ga": "^2.5.7",
"react-hot-loader": "^4.7.2",
"react-hot-loader": "^4.11.1",
"react-modal": "^3.1.7",
"react-paginate": "^5.2.1",
"react-pose": "^4.0.5",

View file

@ -0,0 +1,7 @@
import { connect } from 'react-redux';
import Comment from './view';
export default connect(
null,
null
)(Comment);

View file

@ -0,0 +1,36 @@
// @flow
import React from 'react';
import relativeDate from 'tiny-relative-date';
type Props = {
author: string,
message: string,
timePosted: number,
};
function Comment(props: Props) {
const { author, timePosted, message } = props;
return (
<li className="comment">
<div className="comment__meta card__actions--between">
<strong>{author || __('Anonymous')}</strong>
<time dateTime={timePosted}>{relativeDate(timePosted)}</time>
</div>
<p>{message}</p>
{/* The following is for adding threaded replies, upvoting and downvoting */}
{/* <div className="comment__actions card__actions--between"> */}
{/* <button className={'button button--primary'}>Reply</button> */}
{/* <span className="comment__actions-wrap"> */}
{/* <button className="comment__action upvote">Up</button> */}
{/* <button className="comment__action downvote">Down</button> */}
{/* </span> */}
{/* </div> */}
</li>
);
}
export default Comment;

View file

@ -0,0 +1,17 @@
import { connect } from 'react-redux';
import { doCommentCreate, makeSelectClaimForUri } from 'lbry-redux';
import { CommentCreate } from './view';
const select = (state, props) => ({
claim: makeSelectClaimForUri(props.uri)(state),
});
const perform = dispatch => ({
createComment: (comment, claimId, channel) => dispatch(doCommentCreate(comment, claimId, channel)),
});
export default connect(
select,
perform
)(CommentCreate);

View file

@ -0,0 +1,83 @@
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
// @flow
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
import { CHANNEL_NEW } from 'constants/claim';
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
import React from 'react';
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
import { FormField, Form } from 'component/common/form';
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
import Button from 'component/button';
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
import ChannelSection from 'component/selectChannel';
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
import usePersistedState from 'util/use-persisted-state';
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
type Props = {
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
uri: string,
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
claim: StreamClaim,
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
createComment: (string, string, string) => void,
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
};
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
export function CommentCreate(props: Props) {
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
const { createComment, claim } = props;
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
const { claim_id: claimId } = claim;
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
const [commentValue, setCommentValue] = usePersistedState(`comment-${claimId}`, '');
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
const [commentAck, setCommentAck] = usePersistedState('comment-acknowledge', false);
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
const [channel, setChannel] = usePersistedState('comment-channel', 'anonymous');
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
function handleCommentChange(event) {
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
setCommentValue(event.target.value);
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
function handleChannelChange(channel) {
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
setChannel(channel);
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
function handleCommentAck(event) {
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
setCommentAck(true);
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
function handleSubmit() {
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
if (channel !== CHANNEL_NEW && commentValue.length) createComment(commentValue, claimId, channel);
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
setCommentValue('');
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
return (
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<React.Fragment>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
{commentAck !== true && (
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
kauffj commented 2019-06-26 18:57:00 +02:00 (Migrated from github.com)
Review

if commentAck is false it looks like this returns nothing, so this could probably be tidied down to one check

if `commentAck` is false it looks like this returns nothing, so this could probably be tidied down to one check
jessopb commented 2019-06-26 20:23:25 +02:00 (Migrated from github.com)
Review

if it's false, it shows you the acknowledgment box.
if it's true, it shows you the commenting tool.

if it's false, it shows you the acknowledgment box. if it's true, it shows you the commenting tool.
<section>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<div className="card__content">
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<div className="media__title">About comments..</div>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
</div>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<div className="card__content">
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<div className="media__subtitle">I acknowledge something.</div>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
</div>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<div className="card__content">
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<Button button="primary" onClick={handleCommentAck} label={__('Got it!')} />
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
</div>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
</section>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
)}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
{commentAck === true && (
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<section>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<Form onSubmit={handleSubmit}>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<div className="card__content">
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<ChannelSection channel={channel} onChannelChange={handleChannelChange} />
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
</div>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<div className="card__content">
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<FormField
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
disabled={channel === CHANNEL_NEW}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
type="textarea"
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
name="content_description"
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
label={__('Comment')}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
placeholder={__('Your comment')}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
value={commentValue}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
onChange={handleCommentChange}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
/>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
</div>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<div className="card__actions">
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
<Button
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
button="primary"
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
disabled={channel === CHANNEL_NEW || !commentValue.length}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
type="submit"
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
label={__('Post')}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
/>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
</div>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
</Form>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
</section>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
)}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
</React.Fragment>
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
);
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).
}
neb-b commented 2019-06-20 04:10:04 +02:00 (Migrated from github.com)
Review

Instead of 'no', this can just be a boolean

Instead of `'no'`, this can just be a boolean
neb-b commented 2019-06-20 04:11:31 +02:00 (Migrated from github.com)
Review

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.

I'm not sure if we need a title along with this? I guess it depends on what that messaging ends up being.
jessopb commented 2019-06-24 05:13:58 +02:00 (Migrated from github.com)
Review

@kauffj was going to do some copy for this section.

@kauffj was going to do some copy for this section.
kauffj commented 2019-06-26 18:55:25 +02:00 (Migrated from github.com)
Review

I am all for consting all special values, but this one could probably be skipped

I am all for `const`ing all special values, but this one could probably be skipped
kauffj commented 2019-06-26 19:00:20 +02:00 (Migrated from github.com)
Review

The new here is a value that comes from <ChannelSection>, which is the right time to use a const (otherwise, when editing ChannelSection, I'd have to check every place it is embedded and manually read all of that code to see if "new" is being used or checked against).

The `new` here is a value that comes from `<ChannelSection>`, which _is_ the right time to use a `const` (otherwise, when editing `ChannelSection`, I'd have to check every place it is embedded and manually read all of that code to see if `"new"` is being used or checked against).

View file

@ -0,0 +1,16 @@
import { connect } from 'react-redux';
import { makeSelectCommentsForUri, doCommentList } from 'lbry-redux';
import CommentsList from './view';
const select = (state, props) => ({
comments: makeSelectCommentsForUri(props.uri)(state),
});
const perform = dispatch => ({
fetchComments: uri => dispatch(doCommentList(uri)),
});
export default connect(
select,
perform
)(CommentsList);

View file

@ -0,0 +1,38 @@
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
// @flow
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
import React, { useEffect } from 'react';
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
import Comment from 'component/comment';
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
type Props = {
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
comments: Array<any>,
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
fetchComments: string => void,
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
uri: string,
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
};
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
function CommentList(props: Props) {
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
const { fetchComments, uri, comments } = props;
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
useEffect(() => {
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
fetchComments(uri);
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
}, [fetchComments, uri]);
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
return (
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
<ul className="comments">
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
{comments &&
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
comments.map(comment => {
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
return (
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
<Comment
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
author={comment.channel_name}
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
claimId={comment.channel_id}
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
commentId={comment.comment_id}
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
key={comment.channel_id + comment.comment_id}
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
message={comment.comment}
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
parentId={comment.parent_id || null}
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
timePosted={comment.timestamp * 1000}
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
/>
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
);
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
})}
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
</ul>
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
);
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
}
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)
export default CommentList;
neb-b commented 2019-06-20 04:19:49 +02:00 (Migrated from github.com)
Review

Comment should be broken into it's own file. Then in CommentsList, pass commentId that can be used to select the comment.

Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file

Comment should be broken into it's own file. Then in CommentsList, pass `commentId` that can be used to select the comment. Then if we ever require more data to display a comment, we only have to update one place, instead of having to pass another prop to it in this file
kauffj commented 2019-06-26 19:01:35 +02:00 (Migrated from github.com)
Review

<strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>

` <strong>{this.props.author ? this.props.author : __("Anonymous") }</strong>`
kauffj commented 2019-06-26 19:01:53 +02:00 (Migrated from github.com)
Review

(note i18n call as well as simplification)

(note i18n call as well as simplification)
kauffj commented 2019-06-26 19:02:21 +02:00 (Migrated from github.com)
Review

comment is always applied as a class, so could be omitted from both sides

comment is always applied as a class, so could be omitted from both sides
osilkin98 commented 2019-06-26 21:47:33 +02:00 (Migrated from github.com)
Review

Use this

{this.props.author}

in place of

  <Button className="button--uri-indicator" navigate={this.props.uri}>
          {inner}
 </Button>
  );
}

The schema you're using is a little out of date, you may want to compare it with the one I have on my branch

Use this ```js {this.props.author} ``` in place of ```js <Button className="button--uri-indicator" navigate={this.props.uri}> {inner} </Button> ); } ``` The schema you're using is a little out of date, you may want to compare it with the one I have on [my branch](https://github.com/osilkin98/lbry-desktop/blob/953ee3988fc6ca4af2514c9dd2a3761764feccfd/src/ui/component/uriIndicator/view.jsx#L6)

View file

@ -154,6 +154,7 @@ export class FormField extends React.PureComponent<Props> {
} else if (type === 'textarea') {
input = (
<fieldset-section>
<label htmlFor={name}>{label}</label>
<textarea type={type} id={name} {...inputProps} />
</fieldset-section>
);

View file

@ -4,12 +4,9 @@ import {
makeSelectContentTypeForUri,
makeSelectMetadataForUri,
makeSelectFileInfoForUri,
doToast,
} from 'lbry-redux';
import { selectUser } from 'lbryinc';
import { doOpenFileInFolder } from 'redux/actions/file';
import { selectHasClickedComment } from 'redux/selectors/app';
import { doClickCommentButton } from 'redux/actions/app';
import FileDetails from './view';
const select = (state, props) => ({
@ -17,14 +14,11 @@ const select = (state, props) => ({
contentType: makeSelectContentTypeForUri(props.uri)(state),
fileInfo: makeSelectFileInfoForUri(props.uri)(state),
metadata: makeSelectMetadataForUri(props.uri)(state),
hasClickedComment: selectHasClickedComment(state),
user: selectUser(state),
});
const perform = dispatch => ({
openFolder: path => dispatch(doOpenFileInFolder(path)),
showSnackBar: message => dispatch(doToast({ message })),
clickCommentButton: () => dispatch(doClickCommentButton()),
});
export default connect(

View file

@ -1,6 +1,5 @@
// @flow
import React, { Fragment, PureComponent } from 'react';
import { Lbryio } from 'lbryinc';
import MarkdownPreview from 'component/common/markdown-preview';
import Button from 'component/button';
import Expandable from 'component/expandable';
@ -12,33 +11,12 @@ type Props = {
metadata: StreamMetadata,
openFolder: string => void,
contentType: string,
clickCommentButton: () => void,
showSnackBar: React$Node => void,
hasClickedComment: boolean,
user: ?any,
};
class FileDetails extends PureComponent<Props> {
constructor() {
super();
(this: any).handleCommentClick = this.handleCommentClick.bind(this);
}
handleCommentClick() {
const { clickCommentButton, showSnackBar } = this.props;
clickCommentButton();
Lbryio.call('user_tag', 'edit', { add: 'comments-waitlist' });
showSnackBar(
<span>
{__('Thanks! Comments are coming soon')}
<sup>TM</sup>
</span>
);
}
render() {
const { claim, contentType, fileInfo, metadata, openFolder, hasClickedComment, user } = this.props;
const { claim, contentType, fileInfo, metadata, openFolder } = this.props;
if (!claim || !metadata) {
return (
@ -104,26 +82,6 @@ class FileDetails extends PureComponent<Props> {
)}
</div>
</Expandable>
<div className="media__info-title">Comments</div>
<div className="card__actions--center">
<Button
data-id="add-comment"
disabled={hasClickedComment}
button="primary"
label={__('Want to comment?')}
onClick={this.handleCommentClick}
/>
</div>
<br />
{hasClickedComment && (
<p className="media__info-text media__info-text--center">
{user
? __('Your support has been added. You will be notified when comments are available.')
: __('Your support has been added. Comments are coming soon.')}
</p>
)}
</Fragment>
);
}

View file

@ -1,43 +1,57 @@
// @flow
import { remote } from 'electron';
import React, { Suspense } from 'react';
import React from 'react';
import LoadingScreen from 'component/common/loading-screen';
import VideoViewer from 'component/viewers/videoViewer';
const AudioViewer = React.lazy<*>(() =>
import(/* webpackChunkName: "audioViewer" */
'component/viewers/audioViewer')
import(
/* webpackChunkName: "audioViewer" */
'component/viewers/audioViewer'
)
);
const DocumentViewer = React.lazy<*>(() =>
import(/* webpackChunkName: "documentViewer" */
'component/viewers/documentViewer')
import(
/* webpackChunkName: "documentViewer" */
'component/viewers/documentViewer'
)
);
const DocxViewer = React.lazy<*>(() =>
import(/* webpackChunkName: "docxViewer" */
'component/viewers/docxViewer')
import(
/* webpackChunkName: "docxViewer" */
'component/viewers/docxViewer'
)
);
const HtmlViewer = React.lazy<*>(() =>
import(/* webpackChunkName: "htmlViewer" */
'component/viewers/htmlViewer')
import(
/* webpackChunkName: "htmlViewer" */
'component/viewers/htmlViewer'
)
);
const PdfViewer = React.lazy<*>(() =>
import(/* webpackChunkName: "pdfViewer" */
'component/viewers/pdfViewer')
import(
/* webpackChunkName: "pdfViewer" */
'component/viewers/pdfViewer'
)
);
// @if TARGET='app'
const ComicBookViewer = React.lazy<*>(() =>
import(/* webpackChunkName: "comicBookViewer" */
'component/viewers/comicBookViewer')
import(
/* webpackChunkName: "comicBookViewer" */
'component/viewers/comicBookViewer'
)
);
const ThreeViewer = React.lazy<*>(() =>
import(/* webpackChunkName: "threeViewer" */
'component/viewers/threeViewer')
import(
/* webpackChunkName: "threeViewer" */
'component/viewers/threeViewer'
)
);
// @endif
@ -174,7 +188,7 @@ class FileRender extends React.PureComponent<Props> {
// @if TARGET='web'
// temp workaround to disabled paid content on web
if (claim && claim.value.fee && claim.value.fee.amount > 0) {
if (claim && claim.value.fee && Number(claim.value.fee.amount) > 0) {
const paidMessage = __(
'Currently, only free content is available on lbry.tv. Try viewing it in the desktop app.'
);

View file

@ -76,7 +76,9 @@ class FileViewer extends React.PureComponent<Props> {
}
this.handleAutoplay(this.props);
window.addEventListener('keydown', this.handleKeyDown);
// Commented out because it would play/pause if you were typing in the comment field
// Need a way to check if you are typing
// window.addEventListener('keydown', this.handleKeyDown);
}
kauffj commented 2019-06-26 19:07:34 +02:00 (Migrated from github.com)
Review

is this functionality being removed? maybe comment out the function too and explain why if it's anticipated that it returns?

is this functionality being removed? maybe comment out the function too and explain why if it's anticipated that it returns?
kauffj commented 2019-06-26 23:57:33 +02:00 (Migrated from github.com)
Review

@jessopb I'm fixing most of my own comments but I don't know what or why this was changed, so I'm leaving as is

@jessopb I'm fixing most of my own comments but I don't know what or why this was changed, so I'm leaving as is
componentDidUpdate(prev: Props) {

View file

@ -157,7 +157,13 @@ class ChannelSection extends React.PureComponent<Props, State> {
<BusyIndicator message="Updating channels" />
) : (
<fieldset-section>
<FormField name="channel" type="select" onChange={this.handleChannelChange} value={channel}>
<FormField
name="channel"
label={__('Channel')}
type="select"
onChange={this.handleChannelChange}
value={channel}
>
<option value={CHANNEL_ANONYMOUS}>{__('Anonymous')}</option>
{channels.map(({ name }) => (
<option key={name} value={name}>

View file

@ -1,10 +1,12 @@
// @flow
import React, { Suspense } from 'react';
import React from 'react';
import { stopContextMenu } from 'util/context-menu';
import analytics from 'analytics';
import(/* webpackChunkName: "videojs" */
/* webpackPreload: true */
'video.js/dist/video-js.css');
import(
/* webpackChunkName: "videojs" */
/* webpackPreload: true */
'video.js/dist/video-js.css'
);
type Props = {
source: {
@ -44,10 +46,12 @@ class AudioVideoViewer extends React.PureComponent<Props> {
sources,
};
import(/* webpackChunkName: "videojs" */
/* webpackMode: "lazy" */
/* webpackPreload: true */
'video.js').then(videojs => {
import(
/* webpackChunkName: "videojs" */
/* webpackMode: "lazy" */
/* webpackPreload: true */
'video.js'
).then(videojs => {
if (videojs.__esModule) {
videojs = videojs.default;
this.player = videojs(this.videoNode, videoJsOptions, () => {});

View file

@ -20,6 +20,8 @@ import classnames from 'classnames';
import getMediaType from 'util/get-media-type';
import RecommendedContent from 'component/recommendedContent';
import ClaimTags from 'component/claimTags';
import CommentsList from 'component/commentsList';
import CommentCreate from 'component/commentCreate';
type Props = {
claim: StreamClaim,
@ -285,6 +287,10 @@ class FilePage extends React.Component<Props> {
</div>
<div className="media__info--large">
<FileDetails uri={uri} />
<div className="media__info-title">{__('Comments')}</div>
<CommentCreate uri={uri} />
<CommentsList uri={uri} />
</div>
</div>
<div className="grid-area--related">

View file

@ -7,6 +7,7 @@ import {
walletReducer,
notificationsReducer,
tagsReducerBuilder,
commentReducer,
} from 'lbry-redux';
import { userReducer, rewardsReducer, costInfoReducer, blacklistReducer, homepageReducer, statsReducer } from 'lbryinc';
import appReducer from 'redux/reducers/app';
@ -34,6 +35,7 @@ export default history =>
availability: availabilityReducer,
blacklist: blacklistReducer,
claims: claimsReducer,
comments: commentReducer,
content: contentReducer,
costInfo: costInfoReducer,
fileInfo: fileInfoReducer,

View file

@ -36,6 +36,7 @@ export type AppState = {
isUpgradeAvailable: ?boolean,
isUpgradeSkipped: ?boolean,
hasClickedComment: boolean,
enhancedLayout: boolean,
searchOptionsExpanded: boolean,
};

View file

@ -13,6 +13,7 @@
@import 'component/button';
@import 'component/card';
@import 'component/channel';
@import 'component/comments';
@import 'component/content';
@import 'component/credit';
@import 'component/dat-gui';

View file

@ -25,10 +25,6 @@
.card--section {
position: relative;
padding: var(--spacing-large);
.card__content:not(:last-of-type) {
margin-bottom: var(--spacing-large);
}
}
.card--space-between {
@ -100,6 +96,10 @@
// C O N T E N T
.card__content {
&:not(:last-of-type) {
margin-bottom: var(--spacing-medium);
}
p:not(:last-child) {
margin-bottom: var(--spacing-medium);
}

View file

@ -0,0 +1,55 @@
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
.comments {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
margin-top: var(--spacing-large);
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
}
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
.comment {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
padding: var(--spacing-medium) 0;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
&:not(:last-of-type) {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
border-bottom: 1px solid var(--lbry-gray-1);
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
[data-mode='dark'] & {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
border-color: rgba($lbry-gray-5, 0.2);
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
}
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
}
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
}
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// .comment__actions-wrap {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// align-items: center;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// display: flex;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// justify-content: space-between;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// width: 4.5rem;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// }
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// .comment__action {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// @include hide-text;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// width: 0;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// height: 0;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// transition: border-color 0.2s;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// &.downvote {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// border-top: 2rem solid var(--lbry-orange-3);
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// border-right: 1rem solid transparent;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// border-left: 1rem solid transparent;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// &:hover {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// border-top-color: var(--lbry-yellow-3);
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// }
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// }
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// &.upvote {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// border-right: 1rem solid transparent;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// border-bottom: 2rem solid var(--lbry-teal-4);
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// border-left: 1rem solid transparent;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// &:hover {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// border-bottom-color: var(--lbry-green-2);
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// }
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// }
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
// }
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
.comment__meta {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
time {
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
opacity: 0.3;
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
}
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used
}
osilkin98 commented 2019-06-24 08:09:50 +02:00 (Migrated from github.com)
Review

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.

We're not doing upvotes/downvotes. The only time I can see that is if when move to using claims as comments, we can count supports with say, 10 confirmations as being upvotes.
kauffj commented 2019-06-26 19:04:06 +02:00 (Migrated from github.com)
Review

this should be the class comment--reply and be a first-class rule (i.e. not nested) if we're following BEM

this should be the class `comment--reply` and be a first-class rule (i.e. not nested) if we're following BEM
kauffj commented 2019-06-26 19:05:04 +02:00 (Migrated from github.com)
Review

please comment out any CSS that is not being used

please comment out any CSS that is not being used

View file

@ -4,7 +4,12 @@ export default function usePersistedState(key, firstTimeDefault) {
// If no key is passed in, act as a normal `useState`
let defaultValue;
if (key) {
defaultValue = localStorage.getItem(key);
const item = localStorage.getItem(key);
if (item === 'true') {
defaultValue = true;
} else if (item === 'false') {
defaultValue = false;
}
}
if (!defaultValue) {

View file

@ -287,5 +287,11 @@
"% complete": "% complete",
"Updates published": "Updates published",
"Your updates have been published to LBRY at the address": "Your updates have been published to LBRY at the address",
"The updates will take a few minutes to appear for other LBRY users. Until then your file will be listed as \"pending\" under your published files.": "The updates will take a few minutes to appear for other LBRY users. Until then your file will be listed as \"pending\" under your published files."
"The updates will take a few minutes to appear for other LBRY users. Until then your file will be listed as \"pending\" under your published files.": "The updates will take a few minutes to appear for other LBRY users. Until then your file will be listed as \"pending\" under your published files.",
"Comments": "Comments",
"Comment": "Comment",
"Your comment": "Your comment",
"Post": "Post",
"Channel": "Channel",
"No modifier provided after separator %s.": "No modifier provided after separator %s."
}

View file

@ -6641,9 +6641,9 @@ lazy-val@^1.0.3, lazy-val@^1.0.4:
yargs "^13.2.2"
zstd-codec "^0.1.1"
lbry-redux@lbryio/lbry-redux#3c862e72b36e620155b9c968be9b2bcbd9e0580c:
lbry-redux@lbryio/lbry-redux#141593500693a93db74c62ef5a9fe67b43896603:
version "0.0.1"
resolved "https://codeload.github.com/lbryio/lbry-redux/tar.gz/3c862e72b36e620155b9c968be9b2bcbd9e0580c"
resolved "https://codeload.github.com/lbryio/lbry-redux/tar.gz/141593500693a93db74c62ef5a9fe67b43896603"
dependencies:
proxy-polyfill "0.1.6"
reselect "^3.0.0"
@ -9469,10 +9469,10 @@ react-ga@^2.5.7:
resolved "https://registry.yarnpkg.com/react-ga/-/react-ga-2.5.7.tgz#1c80a289004bf84f84c26d46f3a6a6513081bf2e"
integrity sha512-UmATFaZpEQDO96KFjB5FRLcT6hFcwaxOmAJZnjrSiFN/msTqylq9G+z5Z8TYzN/dbamDTiWf92m6MnXXJkAivQ==
react-hot-loader@^4.7.2:
version "4.8.7"
resolved "https://registry.yarnpkg.com/react-hot-loader/-/react-hot-loader-4.8.7.tgz#8bcec3105d4e0e3cba52aa59800568fc9fb3322d"
integrity sha512-ctWAu8iwp37qd4w1qhjN6neDA1e5bSmAUY46L2l5SeK+i8AfzX+7lrpaLW4TJVaiBv5MlqIzA1ClNnvlvsy5Lg==
react-hot-loader@^4.11.1:
version "4.11.1"
resolved "https://registry.yarnpkg.com/react-hot-loader/-/react-hot-loader-4.11.1.tgz#2cabbd0f1c8a44c28837b86d6ce28521e6d9a8ac"
integrity sha512-HAC0UedYzM3mD+ZaQHesntFO0yi2ftOV4ZMMRTj43E4GvW5sQqYTPvur+6J7EaH3MDr/RqjDKXyCqKepV8+y7w==
dependencies:
fast-levenshtein "^2.0.6"
global "^4.3.0"
@ -11213,6 +11213,11 @@ tiny-invariant@^1.0.2:
resolved "https://registry.yarnpkg.com/tiny-invariant/-/tiny-invariant-1.0.4.tgz#346b5415fd93cb696b0c4e8a96697ff590f92463"
integrity sha512-lMhRd/djQJ3MoaHEBrw8e2/uM4rs9YMNk0iOr8rHQ0QdbM7D4l0gFl3szKdeixrlyfm9Zqi4dxHCM2qVG8ND5g==
tiny-relative-date@^1.3.0:
version "1.3.0"
resolved "https://registry.yarnpkg.com/tiny-relative-date/-/tiny-relative-date-1.3.0.tgz#fa08aad501ed730f31cc043181d995c39a935e07"
integrity sha512-MOQHpzllWxDCHHaDno30hhLfbouoYlOI8YlMNtvKe1zXbjEVhbcEovQxvZrPvtiYW630GQDoMMarCnjfyfHA+A==
tiny-warning@^1.0.0:
version "1.0.2"
resolved "https://registry.yarnpkg.com/tiny-warning/-/tiny-warning-1.0.2.tgz#1dfae771ee1a04396bdfde27a3adcebc6b648b28"