LBRYCommunity/spee.ch
1
0
Fork 0
Code Issues 95 Pull requests 2 Projects Releases 4 Packages Wiki Activity

React router #343

Merged
bones7242 merged 96 commits from react-router into master 2018-02-15 08:02:17 +01:00
Conversation 3 Commits 96 Files changed 111 +2043 -1580
bones7242 commented 2018-02-05 05:35:43 +01:00 (Migrated from github.com)
Copy link
  • added react-router
  • rewrote relevant handlebars templates/partials as react components
  • updated api routes to serve react
- added react-router - rewrote relevant handlebars templates/partials as react components - updated api routes to serve react
neb-b (Migrated from github.com) requested changes 2018-02-05 22:53:41 +01:00
neb-b (Migrated from github.com) left a comment
Copy link

Initial comments. I'll do another look through later. Looking great though!

Initial comments. I'll do another look through later. Looking great though!
react/actions/show.js
neb-b (Migrated from github.com) commented 2018-02-05 20:57:15 +01:00
Copy link

I think generally the pattern is that an action is { type: "some string", data: { name, id... } } just to keep things consistent. data can be an object or a string, but I think it's helpful to put everything inside of that

I think generally the pattern is that an action is `{ type: "some string", data: { name, id... } }` just to keep things consistent. `data` can be an object or a string, but I think it's helpful to put everything inside of that
react/components/AssetDisplay/index.js
neb-b (Migrated from github.com) commented 2018-02-05 20:47:37 +01:00
Copy link

Why do you do const that = this?

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

I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same <AssetDisplay /> it will make these requests again, even if you just made them a second ago

I think this is another piece you can move entirely into redux. Currently if this component is rendered, then a user navigates away and comes back to the same `<AssetDisplay />` it will make these requests again, even if you just made them a second ago
react/components/AssetInfo/index.js
neb-b (Migrated from github.com) commented 2018-02-05 20:39:44 +01:00
Copy link

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

This should be a `button` if it isn't linking anywhere.
react/components/AssetPreview/index.js
neb-b (Migrated from github.com) commented 2018-02-05 20:38:50 +01:00
Copy link

Any reason these aren't just css?

Any reason these aren't just css?
react/components/ShowAssetLite/index.js
neb-b (Migrated from github.com) commented 2018-02-05 20:34:53 +01:00
Copy link

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

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

Then you can just use name={name}

You can use destructuring twice to avoid all the repeated `this.props.claimData` `const { claimData: { name, claimId... } } = this.props` Then you can just use `name={name}`
react/containers/ChannelClaimsDisplay/index.js
neb-b (Migrated from github.com) commented 2018-02-05 20:27:54 +01:00
Copy link

Will these nested values always exist?

Will these nested values always exist?
react/containers/ChannelClaimsDisplay/view.jsx
neb-b (Migrated from github.com) commented 2018-02-05 20:26:45 +01:00
Copy link

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

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

Instead of having a activeClassName prop, it might be simpler to use an active prop. Then you can just change the active class name once inside the NavLink component

Instead of having a `activeClassName` prop, it might be simpler to use an `active` prop. Then you can just change the active class name once inside the `NavLink` component
react/containers/PublishForm/view.jsx
@ -121,3 +114,3 @@
.then(() => {
return that.validatePublishParams();
return this.validatePublishParams();
})
neb-b (Migrated from github.com) commented 2018-02-05 20:15:43 +01:00
Copy link

Not really a comment on this PR but it might be worth looking into fetch instead of dealing with xhr

Not really a comment on this PR but it might be worth looking into `fetch` instead of dealing with `xhr`
react/reducers/show.js
neb-b (Migrated from github.com) commented 2018-02-05 20:12:41 +01:00
Copy link

In the app we use a util to avoid a lot of the boiler plate with redux.
https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js

It just makes it so you don't need to use a switch. I really like it.

In the app we use a util to avoid a lot of the boiler plate with redux. https://github.com/lbryio/lbry-app/blob/master/src/renderer/util/redux-utils.js It just makes it so you don't need to use a switch. I really like it.
react/root.js
neb-b (Migrated from github.com) commented 2018-02-05 20:10:19 +01:00
Copy link

Probably worth adding a 404 page or just redirect to the homepage if it doesn't find a route. Either with a Redirect component or just a route with no path prop.

Probably worth adding a 404 page or just redirect to the homepage if it doesn't find a route. Either with a `Redirect` component or just a route with no `path` prop.
views/index.handlebars
@ -4,3 +2,4 @@
<div id="react-app" class="row row--tall flex-container--column">
<div class="row row--padded row--tall flex-container--column flex-container--center-center">
<p>loading...</p>
{{> progressBar}}
neb-b (Migrated from github.com) commented 2018-02-05 20:14:26 +01:00
Copy link

Not sure if you meant to keep this in? I think this will always be rendered.

Not sure if you meant to keep this in? I think this will always be rendered.
bones7242 (Migrated from github.com) reviewed 2018-02-07 00:13:24 +01:00
react/components/AssetDisplay/index.js
bones7242 (Migrated from github.com) commented 2018-02-07 00:13:24 +01:00
Copy link

I had a misunderstanding of how the this context works and when I needed to pass this in to a function manually. I was able to remove it from the app in multiple places where it isn't necessary.

I had a misunderstanding of how the `this` context works and when I needed to pass this in to a function manually. I was able to remove it from the app in multiple places where it isn't necessary.
bones7242 (Migrated from github.com) reviewed 2018-02-07 07:28:57 +01:00
react/components/AssetPreview/index.js
bones7242 (Migrated from github.com) commented 2018-02-07 07:28:57 +01:00
Copy link

oops

oops
bones7242 (Migrated from github.com) reviewed 2018-02-07 07:58:43 +01:00
react/containers/ChannelClaimsDisplay/index.js
bones7242 (Migrated from github.com) commented 2018-02-07 07:58:43 +01:00
Copy link

They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?

They will always exist when ChannelClaimsDisplay is rendered, unless that should change... I am updated it to be destructured, is that what you were thinking?
neb-b (Migrated from github.com) reviewed 2018-02-07 08:10:06 +01:00
react/containers/ChannelClaimsDisplay/index.js
neb-b (Migrated from github.com) commented 2018-02-07 08:10:06 +01:00
Copy link

I was just wondering if there would ever be a case when show is undefined. Which would cause an errror. cannot read property 'showChannel of undefined`.

Or if any of those children would be undefined which would throw an error

I was just wondering if there would ever be a case when `show` is undefined. Which would cause an errror. `cannot read property 'showChannel` of undefined`. Or if any of those children would be undefined which would throw an error
bones7242 (Migrated from github.com) reviewed 2018-02-09 20:19:28 +01:00
views/index.handlebars
@ -4,3 +2,4 @@
<div id="react-app" class="row row--tall flex-container--column">
<div class="row row--padded row--tall flex-container--column flex-container--center-center">
<p>loading...</p>
{{> progressBar}}
bones7242 (Migrated from github.com) commented 2018-02-09 20:19:28 +01:00
Copy link

I meant to keep the loading bar in so it will render until the app is rendered. Once the app renders it replaces the content of the div and removes the loading bar.

I meant to keep the loading bar in so it will render until the app is rendered. Once the app renders it replaces the content of the div and removes the loading bar.
bones7242 (Migrated from github.com) reviewed 2018-02-09 20:21:03 +01:00
react/containers/PublishForm/view.jsx
@ -121,3 +114,3 @@
.then(() => {
return that.validatePublishParams();
return this.validatePublishParams();
})
bones7242 (Migrated from github.com) commented 2018-02-09 20:21:03 +01:00
Copy link

Cool. Yeah, I replaced most xhr requests with fetch in the app. I kept this one for the publish request because I wanted to set event listeners on the request and wasn't sure if I could do that with fetch. I'll look into that.

Cool. Yeah, I replaced most xhr requests with fetch in the app. I kept this one for the publish request because I wanted to set event listeners on the request and wasn't sure if I could do that with fetch. I'll look into that.
bones7242 (Migrated from github.com) reviewed 2018-02-09 20:25:45 +01:00
react/containers/NavBar/view.jsx
bones7242 (Migrated from github.com) commented 2018-02-09 20:25:45 +01:00
Copy link

I'm not quite sure I understand. Do you mean create my own NavLink component ( rather than using the NavLink from react-router-dom) and control the className from inside the component?

I'm not quite sure I understand. Do you mean create my own `NavLink` component ( rather than using the `NavLink` from `react-router-dom`) and control the className from inside the component?
bones7242 (Migrated from github.com) reviewed 2018-02-09 20:29:01 +01:00
react/reducers/show.js
bones7242 (Migrated from github.com) commented 2018-02-09 20:29:01 +01:00
Copy link

Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.

Hmm, I like the readability of the switch statement, but I might use this util instead. I have to look at the app and see exactly how it works.
neb-b (Migrated from github.com) reviewed 2018-02-09 20:57:10 +01:00
react/reducers/show.js
neb-b (Migrated from github.com) commented 2018-02-09 20:57:10 +01:00
Copy link

Here is an example of it in the app
https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99

Here is an example of it in the app https://github.com/lbryio/lbry-app/blob/master/src/renderer/redux/reducers/shape_shift.js#L99
neb-b (Migrated from github.com) reviewed 2018-02-09 21:17:09 +01:00
react/containers/NavBar/view.jsx
neb-b (Migrated from github.com) commented 2018-02-09 21:17:08 +01:00
Copy link

Oh I didn't realize that was a react-router-dom component. But yeah, I would make a custom NavLink component that uses the react-router-dom component. Then you can extend the functionality/style very easily.

Oh I didn't realize that was a `react-router-dom` component. But yeah, I would make a custom `NavLink` component that uses the `react-router-dom` component. Then you can extend the functionality/style very easily.
neb-b (Migrated from github.com) reviewed 2018-02-09 21:17:28 +01:00
react/containers/NavBar/view.jsx
neb-b (Migrated from github.com) commented 2018-02-09 21:17:28 +01:00
Copy link

similar to this https://github.com/lbryio/lbry-app/blob/redesign-wip/src/renderer/component/link/view.jsx

similar to this https://github.com/lbryio/lbry-app/blob/redesign-wip/src/renderer/component/link/view.jsx
neb-b (Migrated from github.com) requested changes 2018-02-12 20:04:19 +01:00
neb-b (Migrated from github.com) left a comment
Copy link

Looks good. Just some concerns with how you are bringing in some of the already fetched data. I think that can be taken out of the component.

Looks good. Just some concerns with how you are bringing in some of the already fetched data. I think that can be taken out of the component.
helpers/errorHandlers.js
@ -1,51 +1,30 @@
const logger = require('winston');
module.exports = {
handleErrorResponse: function (originalUrl, ip, error, res) {
neb-b (Migrated from github.com) commented 2018-02-09 22:30:08 +01:00
Copy link

Why changing to 200?

Why changing to 200?
react/sagas/show_channel.js
neb-b (Migrated from github.com) commented 2018-02-09 22:53:34 +01:00
Copy link

I don't have any experience using redux-saga so I might just not understand what is happening.

Generally you want XX_SUCCESS and XX_FAIL actions separated. That makes it a lot easier handling the data on the reducer.

I don't have any experience using `redux-saga` so I might just not understand what is happening. Generally you want `XX_SUCCESS` and `XX_FAIL` actions separated. That makes it a lot easier handling the data on the reducer.
neb-b (Migrated from github.com) commented 2018-02-09 22:55:57 +01:00
Copy link

If these aren't being used anywhere else, I don't think they need to be separated.

IMO it would make these saga files easier to understand/follow, but not a big issue

If these aren't being used anywhere else, I don't think they need to be separated. IMO it would make these saga files easier to understand/follow, but not a big issue
bones7242 (Migrated from github.com) reviewed 2018-02-13 05:13:54 +01:00
helpers/errorHandlers.js
@ -1,51 +1,30 @@
const logger = require('winston');
module.exports = {
handleErrorResponse: function (originalUrl, ip, error, res) {
bones7242 (Migrated from github.com) commented 2018-02-13 05:13:54 +01:00
Copy link

I am trying to create a pattern where the server responds with a 200 as long as it processed the request correctly, and then responds with a success and a message or data field. I.e. {"success": "false", "message": "connection refused. The daemon may not be running"}. This way, if the client wanted some data but the daemon was off, it would get a 200 response that the request was completed, and then the client could check the response to see if it was successful or not and whether the data is present. My goal was to help myself (and api users) to distinguish between an error where something was unavailable but the request was handled properly (resulting in a 200) vs a request that I thought would be handled but wasn't, resulting in some other error. Thoughts?

I am trying to create a pattern where the server responds with a 200 as long as it processed the request correctly, and then responds with a `success` and a `message` or `data` field. I.e. `{"success": "false", "message": "connection refused. The daemon may not be running"}`. This way, if the client wanted some data but the daemon was off, it would get a `200` response that the request was completed, and then the client could check the response to see if it was successful or not and whether the data is present. My goal was to help myself (and api users) to distinguish between an error where something was unavailable but the request was handled properly (resulting in a `200`) vs a request that I thought would be handled but wasn't, resulting in some other error. Thoughts?
neb-b (Migrated from github.com) reviewed 2018-02-13 05:45:11 +01:00
helpers/errorHandlers.js
@ -1,51 +1,30 @@
const logger = require('winston');
module.exports = {
handleErrorResponse: function (originalUrl, ip, error, res) {
neb-b (Migrated from github.com) commented 2018-02-13 05:45:11 +01:00
Copy link

I think proper error codes would still be preferable. Even if the request is handled properly, there is still an error. If I see a 200 response, I assume my request was successful. The fetch api handles errors really nicely too, so I think if anything you are creating more work.

fetch('spee.ch/xxx')
  .then((data) => ...)         // successful
  .catch((error) => ...)       // not successful



fetch('spee.ch/xxx')
  .then((data) => {           // maybe successful?
    if (!data.success) {
      throw new Error()
   }
    ...                       // ok now I know it was successful
  })
  .catch((err) => ... )       // not successful

In my opinion it doesn't really matter if a request was handled successfully. If the data doesn't make it, it still fails. You can still add info with the error message and code.

I think proper error codes would still be preferable. Even if the request is handled properly, there is still an error. If I see a 200 response, I assume my request was successful. The `fetch` api handles errors really nicely too, so I think if anything you are creating more work. ``` fetch('spee.ch/xxx') .then((data) => ...) // successful .catch((error) => ...) // not successful fetch('spee.ch/xxx') .then((data) => { // maybe successful? if (!data.success) { throw new Error() } ... // ok now I know it was successful }) .catch((err) => ... ) // not successful ``` In my opinion it doesn't really matter if a request was handled successfully. If the data doesn't make it, it still fails. You can still add info with the error message and code.
neb-b (Migrated from github.com) requested changes 2018-02-13 06:16:02 +01:00
neb-b (Migrated from github.com) left a comment
Copy link

I think you are nearly there with the mapStateToProps improvements. Just need to pull the last bit of un-needed logic out of the component.

I think you are nearly there with the `mapStateToProps` improvements. Just need to pull the last bit of un-needed logic out of the component.
react/actions/show.js
neb-b (Migrated from github.com) commented 2018-02-13 06:05:56 +01:00
Copy link

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

This probably shouldn't be called `XXX_ASYNC` since it isn't async
react/containers/ShowAsset/view.jsx
neb-b (Migrated from github.com) commented 2018-02-13 06:13:36 +01:00
Copy link

I think you are still creating more work than necessary with this. In my opinion previousRequest shouldn't even exist. In the mapStateToProps you should be able to map the asset from your state into the component. If !asset then make the request.

I also think onShowNewAsset and onNewRequest can be combined. More specifically I don't think onShowNewAsset is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".

I think you are still creating more work than necessary with this. In my opinion `previousRequest` shouldn't even exist. In the `mapStateToProps` you should be able to map the `asset` from your state into the component. If `!asset` then make the request. I also think `onShowNewAsset` and `onNewRequest` can be combined. More specifically I don't think `onShowNewAsset` is needed. It might just be my lack of understanding with the current data flow, but you shouldn't need to manually say "show this asset". A better approach would be "select the asset with this id".
react/containers/ShowChannel/view.jsx
neb-b (Migrated from github.com) commented 2018-02-13 06:15:15 +01:00
Copy link

Same comments above about previousRequest. I think a more understandable approach would just be:

if (!channel) this.props.onNewChannelRequest(...)
Same comments above about `previousRequest`. I think a more understandable approach would just be: ``` if (!channel) this.props.onNewChannelRequest(...) ```
bones7242 (Migrated from github.com) reviewed 2018-02-13 21:21:24 +01:00
helpers/errorHandlers.js
@ -1,51 +1,30 @@
const logger = require('winston');
module.exports = {
handleErrorResponse: function (originalUrl, ip, error, res) {
bones7242 (Migrated from github.com) commented 2018-02-13 21:21:24 +01:00
Copy link

That makes a lot of sense, and I was running into a lot of the latter situation where I had to check success in addition to checking for errors. I updated it and that cleaned up the response handling a lot.

That makes a lot of sense, and I was running into a lot of the latter situation where I had to check `success` in addition to checking for errors. I updated it and that cleaned up the response handling a lot.
bones7242 (Migrated from github.com) reviewed 2018-02-14 02:17:20 +01:00
react/containers/ShowAsset/view.jsx
bones7242 (Migrated from github.com) commented 2018-02-14 02:17:20 +01:00
Copy link

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

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

See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.

See above re: previous request. I mostly fixed this, but not sure if more consolidation can be done.
bones7242 commented 2018-02-14 21:32:12 +01:00 (Migrated from github.com)
Copy link

@seanyesmunt I was able to pull the request validation out of <ShowAsset /> and remove that component entirely so that <ShowPage /> triggers the onNewChannelRequest or onNewAssetRequest actions. Those actions then retrieve the data and create the request along with the asset or channel. I also consolidated the channelRequests and assetRequests into one requestList. What do you think?

@seanyesmunt I was able to pull the request validation out of `<ShowAsset />` and remove that component entirely so that `<ShowPage />` triggers the `onNewChannelRequest` or `onNewAssetRequest` actions. Those actions then retrieve the data and create the `request` along with the `asset` or `channel`. I also consolidated the `channelRequests` and `assetRequests` into one `requestList`. What do you think?
neb-b commented 2018-02-14 22:30:50 +01:00 (Migrated from github.com)
Copy link

@billbitt Looks great. The components are definitely a lot simpler. I'm just now thinking that most of the logic inside react/containers/ShowPage/view.jsx can be moved into redux still. You can fetch the actual asset directly after fetching the longForm if you haven't seen that longForm before. No need to wait for the ShowPage to render to make the actual asset request.

Not a super big deal, but I think that should be done at some point. I started on some pseudo code and got a little carried away lol. But I think it could look something like this

// ShowPage.jsx
class ShowPage extends React.Component {
  componentDidMount() {
    this.props.handleShowPageUri(this.props.match.params)
  }

  render() { ... }
}

// Asset redux saga
function handleShowPageUri({ uri }) {
  if (!isValidUri(uri)) { // parse the uri just to make sure its valid
    dispatch(someError())
    return
  }

  // If this uri is in the request list, it's already been fetched
  if (state.requestsList[uri]) {
    return;
  }

  // Haven't seen this uri before
  return getLongForm(uri)
    .then((longForm) => {
      dispatch(addUriToRequestsList(uri))

      if (state.assetList[longForm]) {
        // we already have it, do nothing
        return
      } else {
        fetchAsset(uri)
          .then((asset) => {
            dispatch(addAsset(asset))
          })
      }
    })
}
@billbitt Looks great. The components are definitely a lot simpler. I'm just now thinking that most of the logic inside `react/containers/ShowPage/view.jsx` can be moved into redux still. You can fetch the actual asset directly after fetching the longForm if you haven't seen that longForm before. No need to wait for the `ShowPage` to render to make the actual asset request. Not a super big deal, but I think that should be done at some point. I started on some pseudo code and got a little carried away lol. But I think it could look something like this ``` // ShowPage.jsx class ShowPage extends React.Component { componentDidMount() { this.props.handleShowPageUri(this.props.match.params) } render() { ... } } // Asset redux saga function handleShowPageUri({ uri }) { if (!isValidUri(uri)) { // parse the uri just to make sure its valid dispatch(someError()) return } // If this uri is in the request list, it's already been fetched if (state.requestsList[uri]) { return; } // Haven't seen this uri before return getLongForm(uri) .then((longForm) => { dispatch(addUriToRequestsList(uri)) if (state.assetList[longForm]) { // we already have it, do nothing return } else { fetchAsset(uri) .then((asset) => { dispatch(addAsset(asset)) }) } }) } ```
👍 1
neb-b (Migrated from github.com) approved these changes 2018-02-14 22:31:07 +01:00
bones7242 commented 2018-02-15 03:12:37 +01:00 (Migrated from github.com)
Copy link

@seanyesmunt I moved all that logic out of <ShowPage /> and into a handleShowPageUri action. That action parses it, validates it, and then triggers a onNewChannelRequest or onNewAssetRequest action. In those actions, I added checks to the store to get the lists like in your pseudocode. Can you check it out?

@seanyesmunt I moved all that logic out of `<ShowPage />` and into a `handleShowPageUri` action. That action parses it, validates it, and then triggers a `onNewChannelRequest` or `onNewAssetRequest` action. In those actions, I added checks to the `store` to get the lists like in your pseudocode. Can you check it out?
neb-b (Migrated from github.com) reviewed 2018-02-15 03:30:03 +01:00
react/sagas/show_uri.js
@ -0,0 +9,4 @@
// claim will be an asset claim
// the identifier could be a channel or a claim id
let isChannel, channelName, channelClaimId, claimId, claimName, extension;
try {
neb-b (Migrated from github.com) commented 2018-02-15 03:30:03 +01:00
Copy link

I think you need to add a state check here too. To see if that request exists. It looks like it will add the request to the list every time.

I think you need to add a state check here too. To see if that request exists. It looks like it will add the request to the list every time.
Sign in to join this conversation.
Reviewers
No reviewers
neb-b
Labels
Clear labels   
area: devops

   
area: discovery

   
area: docs

   
area: livestream

   
area: proposal

Work is part of a proposal

  
consider soon

Discuss this issue at the next planning meeting, then remove this label

  
dependencies

Pull requests that update a dependency file

  
Epic

   
good first issue

   
hacktoberfest

Welcome to Hacktoberfest

  
help wanted

   
icebox

Long-term storage

  
level: 1

No knowledge of the existing code required

  
level: 2

Some knowledge of the existing code is recommended

  
level: 3

Significant knowledge of the existing code is recommended

  
level: 4

Intimate knowledge of the existing code is recommended

  
needs: exploration

Solution unclear, needs research

  
needs: grooming

Issue needs to be groomed before work can start

  
needs: priority

Priority level needs to be defined

  
needs: repro

Issue needs step-by-step instructions on how to reproduce in latest code

  
needs: tech design

Needs technical design signoff before implementation can begin

  
on hold

Temporarily paused

  
Osprey

Spee.ch special project

  
priority: blocker

Issue is blocking release, do ASAP

  
priority: high

Work needs to be moved into sprint ASAP

  
priority: low

Work should be done but can stay in the backlog for now

  
priority: medium

Work needs to be done within 2-3 sprints

  
protocol dependent

   
resilience

   
Tom's Wishlist

   
type: bug

Existing functionality is wrong or broken

  
type: discussion

A conversation. No specific changes requested

  
type: error handling

   
type: improvement

Existing (or partially existing) functionality needs to be changed

  
type: new feature

New functionality that does not exist yet

  
type: refactor

Minimal user-visible changes, but significant internal work

  
type: task

Either work that's not related to the code, or a small chore that does not fit into other categories

  
type: testing

Solution needs additional user testing

  
unplanned

Work that was not planned into the spirnt, took priority over planned work

No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
dependencies
Epic
good first issue
hacktoberfest
help wanted
icebox
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
Osprey
priority: blocker
priority: high
priority: low
priority: medium
protocol dependent
resilience
Tom's Wishlist
type: bug
type: discussion
type: error handling
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/spee.ch#343
No description provided.
Delete branch "react-router"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?