0.36.0 SDK changes #2407
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!2407
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "sdk-changes"
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?
Notes
nsfwis checked on publish, it applies thematuretag.@ -1,5 +1,3 @@// @flowimport type { Claim } from 'types/claim';import React from 'react';I removed flow from this file because there were ~30 type errors. If we have flow in a file, it should cover everything so we don't need to constantly use
--no-verifyLooks pretty good to me
@ -0,0 +1,52 @@// @flowdeclare type UpdatePublishFormData = {Naming is a little inconsistent between these two types.
Also, you may be able to use Intersection Types to avoid repeating the shared values across both (but I've never used this feature).
null, notundefined, I think@ -34,3 +31,4 @@costInfo: ?{cost: number},fetchFileInfo: string => void,fetchCostInfo: string => void,setViewed: string => void,It looks like this component both receives the entire
Claimand properties of the claim independently. Should it always be one or the other?@ -398,4 +354,3 @@export function savePosition(claimId: string, outpoint: string, position: number) {return (dispatch: Dispatch) => {dispatch({Nice :D
@ -0,0 +1,52 @@// @flowdeclare type UpdatePublishFormData = {Yeah... the publish types were one of the first added. Now that I have a better idea of flow and have developed some patterns in other parts of the app this can be cleaned up a lot. Planning to clean it up when I add the tags to the publish page
@ -34,3 +31,4 @@costInfo: ?{cost: number},fetchFileInfo: string => void,fetchCostInfo: string => void,setViewed: string => void,I think we should start moving to bring in individual properties that components use: see
makeSelectTitleForUri, instead of large objects if the component only uses a couple of values.It's faster for react to update because then it isn't doing tons of un-needed checks to see if an object changed at all.
Inputs can't use
nullor react throws errors. Something to do with how javascript handlesnullhttps://github.com/facebook/react/issues/11417