Publishing Take 2 #346
No reviewers
Labels
No labels
accessibility
app-parity
area: creator
area: daemon
area: design
area: devops
area: discovery
area: docs
area: installer
area: internal
area: livestream
area: performance
area: proposal
area: reposts
area: rewards
area: search
area: security
area: subscriptions
area: sync
area: ux
area: viewer
area: wallet
BEAMER
channel
comments
community PR
consider soon
core team
css
dependencies
electron
Epic
feature request
first-timers-only
good first issue
hacktoberfest
help wanted
hub-dependent
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
merge when green
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
notifications
odysee
on hold
playlists
priority: blocker
priority: high
priority: low
priority: medium
protocol dependent
recsys
redesign
regression
resilience
sdk dependent
Tom's Wishlist
trending
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbry-desktop#346
Loading…
Reference in a new issue
No description provided.
Delete branch "publishing2"
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?
I ran out of time on review and testing this for today, but here's that set of feedback.
Shouldn't this be reject, at least?
Is there an alternative queuing pattern that could be used here? Or could we simply check if fetch claims is pending via a selector?
Probably merits its own component?
I don't think this needs to change now, and I know this wasn't your work, but this is a pattern worth reconsidering before continuing it further.
Are these binds if necessary? The
() => { }
syntax automatically keeps thethis
context.@ -0,0 +17,4 @@
handleChannelChange(event) {
const channel = event.target.value;
if (channel === "new") this.setState({ addingChannel: true });
Missing braces (mildly surprised this parses)
@ -0,0 +53,4 @@
}
handleCreateChannelClick(event) {
if (this.state.newChannelName.length < 5) {
I'm inclined to drop this restriction (https://github.com/lbryio/lbry/issues/769). But I suppose we ought to keep it for now, especially since the error the daemon gives is unclear.
The
Notice
component was only used here and the style does not match the application. I dropped it.@ -63,7 +63,16 @@ export const FETCH_AVAILABILITY_STARTED = "FETCH_AVAILABILITY_STARTED";
export const FETCH_AVAILABILITY_COMPLETED = "FETCH_AVAILABILITY_COMPLETED";
I would propose that we reserve
_COMPLETED
for async actions that fire regardless of success or failure, and use_SUCCESS
instead for actions that only fire when the async event is successful.The dual view button needs to be added to this list.
@ -0,0 +17,4 @@
handleChannelChange(event) {
const channel = event.target.value;
if (channel === "new") this.setState({ addingChannel: true });
Braces aren't required if there's only one statement. So
is valid
They are not necessary :)
@ -63,7 +63,16 @@ export const FETCH_AVAILABILITY_STARTED = "FETCH_AVAILABILITY_STARTED";
export const FETCH_AVAILABILITY_COMPLETED = "FETCH_AVAILABILITY_COMPLETED";
Good call, I like it.
oops, yes it should.
@ -63,7 +63,16 @@ export const FETCH_AVAILABILITY_STARTED = "FETCH_AVAILABILITY_STARTED";
export const FETCH_AVAILABILITY_COMPLETED = "FETCH_AVAILABILITY_COMPLETED";
maybe
_SUCCEEDED
dual view button?
Sorry @kauffj, I accidentally force pushed over a couple of changes you made :(
The right most button that shows both editor and preview.
@6ea86b96 np re: force push
ok, dropped.
I don't see that in the list of possible types to disallow.
I've added some extra code to disable the submit button if the bid is not higher than the current claim @kauffj
However, I have now noticed that the dual view mode in the publish form is horribly broken.
For now I've just disabled
side-by-side
mode.Definitely need to think about a better solution.
Found and fixed one other bug where if you overwrite an existing claim the old fileinfo shows up in downloaded files.
One more bug I found but have not fixed though.
This is because even though the claim was abandoned the daemon is still returning the first file from the
file_list
command (but not returning the claim anymore inclaim_list_mine
).