Make publishes appear immediately in My Files #14
|
@ -8,9 +8,14 @@ Web UI version numbers should always match the corresponding version of LBRY App
|
||||||
|
|
||||||
## [Unreleased]
|
## [Unreleased]
|
||||||
### Added
|
### Added
|
||||||
|
* The app is much more responsive switching pages. It no longer reloads the entire page and all assets on each page change.
|
||||||
|
* lbry.js now offers a subscription model for wallet balance similar to file info.
|
||||||
|
* Fixed file info subscribes not being unsubscribed in unmount.
|
||||||
|
* Fixed drawer not highlighting selected page.
|
||||||
* You can now make API calls directly on the lbry module, e.g. lbry.peer_list()
|
* You can now make API calls directly on the lbry module, e.g. lbry.peer_list()
|
||||||
* New-style API calls return promises instead of using callbacks
|
* New-style API calls return promises instead of using callbacks
|
||||||
* Wherever possible, use outpoints for unique IDs instead of names or SD hashes
|
* Wherever possible, use outpoints for unique IDs instead of names or SD hashes
|
||||||
|
* New publishes now display immediately in My Files, even before they hit the lbrynet file manager.
|
||||||
|
|
||||||
### Changed
|
### Changed
|
||||||
* Update process now easier and more reliable
|
* Update process now easier and more reliable
|
|
@ -17,7 +17,7 @@ let quitting = false;
|
||||||
|
|
||||||
|
|
||||||
function createWindow () {
|
function createWindow () {
|
||||||
win = new BrowserWindow({backgroundColor: '#155b4a'})
|
win = new BrowserWindow({backgroundColor: '#155B4A'}) //$color-primary
|
||||||
win.maximize()
|
win.maximize()
|
||||||
//win.webContents.openDevTools()
|
//win.webContents.openDevTools()
|
||||||
win.loadURL(`file://${__dirname}/dist/index.html`)
|
win.loadURL(`file://${__dirname}/dist/index.html`)
|
||||||
|
|
42
ui/js/app.js
|
@ -40,9 +40,15 @@ var App = React.createClass({
|
||||||
},
|
},
|
||||||
|
|
||||||
_upgradeDownloadItem: null,
|
_upgradeDownloadItem: null,
|
||||||
|
_isMounted: false,
|
||||||
_version: null,
|
_version: null,
|
||||||
|
|
||||||
// Temporary workaround since electron-dl throws errors when you try to get the filename
|
// Temporary workaround since electron-dl throws errors when you try to get the filename
|
||||||
|
getDefaultProps: function() {
|
||||||
|
return {
|
||||||
|
address: window.location.search
|
||||||
|
};
|
||||||
|
},
|
||||||
getUpgradeFilename: function() {
|
getUpgradeFilename: function() {
|
||||||
if (os.platform() == 'darwin') {
|
if (os.platform() == 'darwin') {
|
||||||
return `LBRY-${this._version}.dmg`;
|
return `LBRY-${this._version}.dmg`;
|
||||||
|
@ -52,33 +58,35 @@ var App = React.createClass({
|
||||||
return `LBRY.Setup.${this._version}.exe`;
|
return `LBRY.Setup.${this._version}.exe`;
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
getInitialState: function() {
|
getViewingPageAndArgs: function(address) {
|
||||||
// For now, routes are in format ?page or ?page=args
|
// For now, routes are in format ?page or ?page=args
|
||||||
var match, param, val, viewingPage,
|
let [isMatch, viewingPage, pageArgs] = address.match(/\??([^=]*)(?:=(.*))?/);
|
||||||
drawerOpenRaw = sessionStorage.getItem('drawerOpen');
|
|
||||||
|
|
||||||
[match, viewingPage, val] = window.location.search.match(/\??([^=]*)(?:=(.*))?/);
|
|
||||||
|
|
||||||
|
|
||||||
return {
|
return {
|
||||||
viewingPage: viewingPage,
|
viewingPage: viewingPage,
|
||||||
|
pageArgs: pageArgs === undefined ? null : pageArgs
|
||||||
|
};
|
||||||
|
},
|
||||||
|
getInitialState: function() {
|
||||||
|
var match, param, val, viewingPage, pageArgs,
|
||||||
|
drawerOpenRaw = sessionStorage.getItem('drawerOpen');
|
||||||
|
|
||||||
|
return Object.assign(this.getViewingPageAndArgs(this.props.address), {
|
||||||
drawerOpen: drawerOpenRaw !== null ? JSON.parse(drawerOpenRaw) : true,
|
drawerOpen: drawerOpenRaw !== null ? JSON.parse(drawerOpenRaw) : true,
|
||||||
pageArgs: typeof val !== 'undefined' ? val : null,
|
|
||||||
errorInfo: null,
|
errorInfo: null,
|
||||||
modal: null,
|
modal: null,
|
||||||
updateUrl: null,
|
updateUrl: null,
|
||||||
isOldOSX: null,
|
isOldOSX: null,
|
||||||
downloadProgress: null,
|
downloadProgress: null,
|
||||||
downloadComplete: false,
|
downloadComplete: false,
|
||||||
};
|
});
|
||||||
},
|
},
|
||||||
componentWillMount: function() {
|
componentWillMount: function() {
|
||||||
document.addEventListener('unhandledError', (event) => {
|
document.addEventListener('unhandledError', (event) => {
|
||||||
this.alertError(event.detail);
|
this.alertError(event.detail);
|
||||||
});
|
});
|
||||||
|
|
||||||
//open links in external browser
|
//open links in external browser and skip full redraw on changing page
|
||||||
document.addEventListener('click', function(event) {
|
document.addEventListener('click', (event) => {
|
||||||
var target = event.target;
|
var target = event.target;
|
||||||
while (target && target !== document) {
|
while (target && target !== document) {
|
||||||
if (target.matches('a[href^="http"]')) {
|
if (target.matches('a[href^="http"]')) {
|
||||||
|
@ -86,6 +94,12 @@ var App = React.createClass({
|
||||||
shell.openExternal(target.href);
|
shell.openExternal(target.href);
|
||||||
return;
|
return;
|
||||||
}
|
}
|
||||||
|
if (target.matches('a[href^="?"]')) {
|
||||||
|
event.preventDefault();
|
||||||
|
if (this._isMounted) {
|
||||||
|
this.setState(this.getViewingPageAndArgs(target.getAttribute('href')));
|
||||||
|
}
|
||||||
|
}
|
||||||
target = target.parentNode;
|
target = target.parentNode;
|
||||||
}
|
}
|
||||||
});
|
});
|
||||||
|
@ -136,6 +150,12 @@ var App = React.createClass({
|
||||||
modal: null,
|
modal: null,
|
||||||
});
|
});
|
||||||
},
|
},
|
||||||
|
componentDidMount: function() {
|
||||||
|
this._isMounted = true;
|
||||||
|
},
|
||||||
|
componentWillUnmount: function() {
|
||||||
|
this._isMounted = false;
|
||||||
|
},
|
||||||
handleUpgradeClicked: function() {
|
handleUpgradeClicked: function() {
|
||||||
// TODO: create a callback for onProgress and have the UI
|
// TODO: create a callback for onProgress and have the UI
|
||||||
// show download progress
|
// show download progress
|
||||||
|
|
|
@ -9,7 +9,7 @@ var DrawerItem = React.createClass({
|
||||||
};
|
};
|
||||||
},
|
},
|
||||||
render: function() {
|
render: function() {
|
||||||
var isSelected = (this.props.viewingPage == this.props.href.substr(2) ||
|
var isSelected = (this.props.viewingPage == this.props.href.substr(1) ||
|
||||||
this.props.subPages.indexOf(this.props.viewingPage) != -1);
|
this.props.subPages.indexOf(this.props.viewingPage) != -1);
|
||||||
return <Link {...this.props} className={ 'drawer-item ' + (isSelected ? 'drawer-item-selected' : '') } />
|
return <Link {...this.props} className={ 'drawer-item ' + (isSelected ? 'drawer-item-selected' : '') } />
|
||||||
}
|
}
|
||||||
|
@ -20,9 +20,11 @@ var drawerImageStyle = { //@TODO: remove this, img should be properly scaled onc
|
||||||
};
|
};
|
||||||
|
|
||||||
var Drawer = React.createClass({
|
var Drawer = React.createClass({
|
||||||
|
_balanceSubscribeId: null,
|
||||||
|
|
||||||
handleLogoClicked: function(event) {
|
handleLogoClicked: function(event) {
|
||||||
if ((event.ctrlKey || event.metaKey) && event.shiftKey) {
|
if ((event.ctrlKey || event.metaKey) && event.shiftKey) {
|
||||||
window.location.href = 'index.html?developer'
|
window.location.href = '?developer'
|
||||||
event.preventDefault();
|
event.preventDefault();
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
|
@ -32,25 +34,30 @@ var Drawer = React.createClass({
|
||||||
};
|
};
|
||||||
},
|
},
|
||||||
componentDidMount: function() {
|
componentDidMount: function() {
|
||||||
lbry.getBalance(function(balance) {
|
this._balanceSubscribeId = lbry.balanceSubscribe(function(balance) {
|
||||||
this.setState({
|
this.setState({
|
||||||
balance: balance
|
balance: balance
|
||||||
});
|
});
|
||||||
}.bind(this));
|
}.bind(this));
|
||||||
},
|
},
|
||||||
|
componentWillUnmount: function() {
|
||||||
|
if (this._balanceSubscribeId) {
|
||||||
|
lbry.balanceUnsubscribe(this._balanceSubscribeId)
|
||||||
|
}
|
||||||
|
},
|
||||||
render: function() {
|
render: function() {
|
||||||
return (
|
return (
|
||||||
<nav id="drawer">
|
<nav id="drawer">
|
||||||
<div id="drawer-handle">
|
<div id="drawer-handle">
|
||||||
<Link title="Close" onClick={this.props.onCloseDrawer} icon="icon-bars" className="close-drawer-link"/>
|
<Link title="Close" onClick={this.props.onCloseDrawer} icon="icon-bars" className="close-drawer-link"/>
|
||||||
<a href="index.html?discover" onMouseUp={this.handleLogoClicked}><img src={lbry.imagePath("lbry-dark-1600x528.png")} style={drawerImageStyle}/></a>
|
<a href="?discover" onMouseUp={this.handleLogoClicked}><img src={lbry.imagePath("lbry-dark-1600x528.png")} style={drawerImageStyle}/></a>
|
||||||
</div>
|
</div>
|
||||||
<DrawerItem href='index.html?discover' viewingPage={this.props.viewingPage} label="Discover" icon="icon-search" />
|
<DrawerItem href='?discover' viewingPage={this.props.viewingPage} label="Discover" icon="icon-search" />
|
||||||
<DrawerItem href='index.html?publish' viewingPage={this.props.viewingPage} label="Publish" icon="icon-upload" />
|
<DrawerItem href='?publish' viewingPage={this.props.viewingPage} label="Publish" icon="icon-upload" />
|
||||||
<DrawerItem href='index.html?downloaded' subPages={['published']} viewingPage={this.props.viewingPage} label="My Files" icon='icon-cloud-download' />
|
<DrawerItem href='?downloaded' subPages={['published']} viewingPage={this.props.viewingPage} label="My Files" icon='icon-cloud-download' />
|
||||||
<DrawerItem href="index.html?wallet" subPages={['send', 'receive', 'claim', 'referral']} viewingPage={this.props.viewingPage} label="My Wallet" badge={lbry.formatCredits(this.state.balance) } icon="icon-bank" />
|
<DrawerItem href="?wallet" subPages={['send', 'receive', 'claim', 'referral']} viewingPage={this.props.viewingPage} label="My Wallet" badge={lbry.formatCredits(this.state.balance) } icon="icon-bank" />
|
||||||
<DrawerItem href='index.html?settings' viewingPage={this.props.viewingPage} label="Settings" icon='icon-gear' />
|
<DrawerItem href='?settings' viewingPage={this.props.viewingPage} label="Settings" icon='icon-gear' />
|
||||||
<DrawerItem href='index.html?help' viewingPage={this.props.viewingPage} label="Help" icon='icon-question-circle' />
|
<DrawerItem href='?help' viewingPage={this.props.viewingPage} label="Help" icon='icon-question-circle' />
|
||||||
</nav>
|
</nav>
|
||||||
);
|
);
|
||||||
}
|
}
|
||||||
|
|
|
@ -179,7 +179,7 @@ let FileActionsRow = React.createClass({
|
||||||
let linkBlock;
|
let linkBlock;
|
||||||
if (this.state.fileInfo === false && !this.state.attemptingDownload) {
|
if (this.state.fileInfo === false && !this.state.attemptingDownload) {
|
||||||
linkBlock = <Link button="text" label="Download" icon="icon-download" onClick={this.onDownloadClick} />;
|
linkBlock = <Link button="text" label="Download" icon="icon-download" onClick={this.onDownloadClick} />;
|
||||||
} else if (this.state.attemptingDownload || !this.state.fileInfo.completed) {
|
} else if (this.state.attemptingDownload || (!this.state.fileInfo.completed && !this.state.fileInfo.isMine)) {
|
||||||
const
|
const
|
||||||
progress = this.state.fileInfo ? this.state.fileInfo.written_bytes / this.state.fileInfo.total_bytes * 100 : 0,
|
progress = this.state.fileInfo ? this.state.fileInfo.written_bytes / this.state.fileInfo.total_bytes * 100 : 0,
|
||||||
label = this.state.fileInfo ? progress.toFixed(0) + '% complete' : 'Connecting...',
|
label = this.state.fileInfo ? progress.toFixed(0) + '% complete' : 'Connecting...',
|
||||||
|
@ -253,7 +253,7 @@ export let FileActions = React.createClass({
|
||||||
if (this.isMounted) {
|
if (this.isMounted) {
|
||||||
this.setState({
|
this.setState({
|
||||||
fileInfo: fileInfo,
|
fileInfo: fileInfo,
|
||||||
});
|
});
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
componentDidMount: function() {
|
componentDidMount: function() {
|
||||||
|
@ -276,6 +276,9 @@ export let FileActions = React.createClass({
|
||||||
},
|
},
|
||||||
componentWillUnmount: function() {
|
componentWillUnmount: function() {
|
||||||
this._isMounted = false;
|
this._isMounted = false;
|
||||||
|
if (this._fileInfoSubscribeId) {
|
||||||
|
lbry.fileInfoUnsubscribe(this.props.outpoint, this._fileInfoSubscribeId);
|
||||||
|
}
|
||||||
},
|
},
|
||||||
render: function() {
|
render: function() {
|
||||||
const fileInfo = this.state.fileInfo;
|
const fileInfo = this.state.fileInfo;
|
||||||
|
|
|
@ -79,7 +79,7 @@ export let FileTileStream = React.createClass({
|
||||||
componentDidMount: function() {
|
componentDidMount: function() {
|
||||||
this._isMounted = true;
|
this._isMounted = true;
|
||||||
if (this.props.hideOnRemove) {
|
if (this.props.hideOnRemove) {
|
||||||
lbry.fileInfoSubscribe(this.props.outpoint, this.onFileInfoUpdate);
|
this._fileInfoSubscribeId = lbry.fileInfoSubscribe(this.props.outpoint, this.onFileInfoUpdate);
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
componentWillUnmount: function() {
|
componentWillUnmount: function() {
|
||||||
|
@ -121,15 +121,15 @@ export let FileTileStream = React.createClass({
|
||||||
<section className={ 'file-tile card ' + (obscureNsfw ? 'card-obscured ' : '') } onMouseEnter={this.handleMouseOver} onMouseLeave={this.handleMouseOut}>
|
<section className={ 'file-tile card ' + (obscureNsfw ? 'card-obscured ' : '') } onMouseEnter={this.handleMouseOver} onMouseLeave={this.handleMouseOut}>
|
||||||
<div className={"row-fluid card-content file-tile__row"}>
|
<div className={"row-fluid card-content file-tile__row"}>
|
||||||
<div className="span3">
|
<div className="span3">
|
||||||
<a href={'/?show=' + this.props.name}><Thumbnail className="file-tile__thumbnail" src={metadata.thumbnail} alt={'Photo for ' + (title || this.props.name)} /></a>
|
<a href={'?show=' + this.props.name}><Thumbnail className="file-tile__thumbnail" src={metadata.thumbnail} alt={'Photo for ' + (title || this.props.name)} /></a>
|
||||||
</div>
|
</div>
|
||||||
<div className="span9">
|
<div className="span9">
|
||||||
{ !this.props.hidePrice
|
{ !this.props.hidePrice
|
||||||
? <FilePrice name={this.props.name} />
|
? <FilePrice name={this.props.name} />
|
||||||
: null}
|
: null}
|
||||||
<div className="meta"><a href={'index.html?show=' + this.props.name}>{'lbry://' + this.props.name}</a></div>
|
<div className="meta"><a href={'?show=' + this.props.name}>{'lbry://' + this.props.name}</a></div>
|
||||||
<h3 className="file-tile__title">
|
<h3 className="file-tile__title">
|
||||||
<a href={'index.html?show=' + this.props.name}>
|
<a href={'?show=' + this.props.name}>
|
||||||
<TruncatedText lines={1}>
|
<TruncatedText lines={1}>
|
||||||
{title}
|
{title}
|
||||||
</TruncatedText>
|
</TruncatedText>
|
||||||
|
|
238
ui/js/lbry.js
|
@ -1,15 +1,103 @@
|
||||||
import lighthouse from './lighthouse.js';
|
import lighthouse from './lighthouse.js';
|
||||||
import jsonrpc from './jsonrpc.js';
|
import jsonrpc from './jsonrpc.js';
|
||||||
|
import {getLocal, setLocal} from './utils.js';
|
||||||
|
|
||||||
const {remote} = require('electron');
|
const {remote} = require('electron');
|
||||||
const menu = remote.require('./menu/main-menu');
|
const menu = remote.require('./menu/main-menu');
|
||||||
|
|
||||||
|
/**
|
||||||
|
* Records a publish attempt in local storage. Returns a dictionary with all the data needed to
|
||||||
|
* needed to make a dummy claim or file info object.
|
||||||
|
*/
|
||||||
|
function savePendingPublish(name) {
|
||||||
|
const pendingPublishes = getLocal('pendingPublishes') || [];
|
||||||
|
const newPendingPublish = {
|
||||||
|
claim_id: 'pending_claim_' + name,
|
||||||
|
txid: 'pending_' + name,
|
||||||
|
nout: 0,
|
||||||
|
outpoint: 'pending_' + name + ':0',
|
||||||
|
name: name,
|
||||||
|
time: Date.now(),
|
||||||
|
};
|
||||||
|
setLocal('pendingPublishes', [...pendingPublishes, newPendingPublish]);
|
||||||
|
return newPendingPublish;
|
||||||
|
}
|
||||||
|
|
||||||
|
function removePendingPublish({name, outpoint}) {
|
||||||
|
setLocal('pendingPublishes', getPendingPublishes().filter(
|
||||||
|
(pub) => pub.name != name && pub.outpoint != outpoint
|
||||||
|
));
|
||||||
|
}
|
||||||
|
|
||||||
|
/**
|
||||||
|
* Gets the current list of pending publish attempts. Filters out any that have timed out and
|
||||||
|
* removes them from the list.
|
||||||
|
*/
|
||||||
|
function getPendingPublishes() {
|
||||||
|
const pendingPublishes = getLocal('pendingPublishes') || [];
|
||||||
|
|
||||||
|
const newPendingPublishes = [];
|
||||||
|
for (let pendingPublish of pendingPublishes) {
|
||||||
|
if (Date.now() - pendingPublish.time <= lbry.pendingPublishTimeout) {
|
||||||
|
newPendingPublishes.push(pendingPublish);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
setLocal('pendingPublishes', newPendingPublishes);
|
||||||
|
return newPendingPublishes
|
||||||
|
}
|
||||||
|
|
||||||
|
/**
|
||||||
|
* Gets a pending publish attempt by its name or (fake) outpoint. If none is found (or one is found
|
||||||
|
* but it has timed out), returns null.
|
||||||
|
*/
|
||||||
|
function getPendingPublish({name, outpoint}) {
|
||||||
|
const pendingPublishes = getPendingPublishes();
|
||||||
|
const pendingPublishIndex = pendingPublishes.findIndex(
|
||||||
|
({name: itemName, outpoint: itemOutpoint}) => itemName == name || itemOutpoint == outpoint
|
||||||
|
);
|
||||||
|
const pendingPublish = pendingPublishes[pendingPublishIndex];
|
||||||
|
|
||||||
|
if (pendingPublishIndex == -1) {
|
||||||
|
return null;
|
||||||
|
} else if (Date.now() - pendingPublish.time > lbry.pendingPublishTimeout) {
|
||||||
|
// Pending publish timed out, so remove it from the stored list and don't match
|
||||||
|
|
||||||
|
const newPendingPublishes = pendingPublishes.slice();
|
||||||
|
newPendingPublishes.splice(pendingPublishIndex, 1);
|
||||||
|
setLocal('pendingPublishes', newPendingPublishes);
|
||||||
|
return null;
|
||||||
|
} else {
|
||||||
|
return pendingPublish;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
function pendingPublishToDummyClaim({name, outpoint, claim_id, txid, nout}) {
|
||||||
|
return {
|
||||||
|
name: name,
|
||||||
|
outpoint: outpoint,
|
||||||
|
claim_id: claim_id,
|
||||||
|
txid: txid,
|
||||||
|
nout: nout,
|
||||||
|
};
|
||||||
|
}
|
||||||
|
|
||||||
|
function pendingPublishToDummyFileInfo({name, outpoint, claim_id}) {
|
||||||
|
return {
|
||||||
|
name: name,
|
||||||
|
outpoint: outpoint,
|
||||||
|
claim_id: claim_id,
|
||||||
|
metadata: "Attempting publication",
|
||||||
|
};
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
let lbry = {
|
let lbry = {
|
||||||
isConnected: false,
|
isConnected: false,
|
||||||
rootPath: '.',
|
rootPath: '.',
|
||||||
daemonConnectionString: 'http://localhost:5279/lbryapi',
|
daemonConnectionString: 'http://localhost:5279/lbryapi',
|
||||||
webUiUri: 'http://localhost:5279',
|
webUiUri: 'http://localhost:5279',
|
||||||
peerListTimeout: 6000,
|
peerListTimeout: 6000,
|
||||||
|
pendingPublishTimeout: 20 * 60 * 1000,
|
||||||
colors: {
|
colors: {
|
||||||
primary: '#155B4A'
|
primary: '#155B4A'
|
||||||
},
|
},
|
||||||
|
@ -223,7 +311,7 @@ lbry.stopFile = function(name, callback) {
|
||||||
|
|
||||||
lbry.removeFile = function(outpoint, deleteTargetFile=true, callback) {
|
lbry.removeFile = function(outpoint, deleteTargetFile=true, callback) {
|
||||||
this._removedFiles.push(outpoint);
|
this._removedFiles.push(outpoint);
|
||||||
this._updateSubscribedFileInfo(outpoint);
|
this._updateFileInfoSubscribers(outpoint);
|
||||||
|
|
||||||
lbry.file_delete({
|
lbry.file_delete({
|
||||||
outpoint: outpoint,
|
outpoint: outpoint,
|
||||||
|
@ -251,18 +339,49 @@ lbry.getFileInfoWhenListed = function(name, callback, timeoutCallback, tryNum=0)
|
||||||
}, () => scheduleNextCheckOrTimeout());
|
}, () => scheduleNextCheckOrTimeout());
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/**
|
||||||
|
* Publishes a file. The optional fileListedCallback is called when the file becomes available in
|
||||||
|
* lbry.file_list() during the publish process.
|
||||||
|
*
|
||||||
|
* This currently includes a work-around to cache the file in local storage so that the pending
|
||||||
|
* publish can appear in the UI immediately.
|
||||||
|
*/
|
||||||
lbry.publish = function(params, fileListedCallback, publishedCallback, errorCallback) {
|
lbry.publish = function(params, fileListedCallback, publishedCallback, errorCallback) {
|
||||||
// Publishes a file.
|
lbry.call('publish', params, (result) => {
|
||||||
// The optional fileListedCallback is called when the file becomes available in
|
if (returnedPending) {
|
||||||
// lbry.getFilesInfo() during the publish process.
|
return;
|
||||||
|
}
|
||||||
|
|
||||||
// Use ES6 named arguments instead of directly passing param dict?
|
clearTimeout(returnPendingTimeout);
|
||||||
lbry.call('publish', params, publishedCallback, errorCallback);
|
publishedCallback(result);
|
||||||
if (fileListedCallback) {
|
}, (err) => {
|
||||||
lbry.getFileInfoWhenListed(params.name, function(fileInfo) {
|
if (returnedPending) {
|
||||||
fileListedCallback(fileInfo);
|
return;
|
||||||
});
|
}
|
||||||
}
|
|
||||||
|
clearTimeout(returnPendingTimeout);
|
||||||
|
errorCallback(err);
|
||||||
|
});
|
||||||
|
|
||||||
|
let returnedPending = false;
|
||||||
|
// Give a short grace period in case publish() returns right away or (more likely) gives an error
|
||||||
|
const returnPendingTimeout = setTimeout(() => {
|
||||||
|
returnedPending = true;
|
||||||
|
|
||||||
|
if (publishedCallback) {
|
||||||
|
savePendingPublish(params.name);
|
||||||
|
publishedCallback(true);
|
||||||
|
}
|
||||||
|
|
||||||
|
if (fileListedCallback) {
|
||||||
|
savePendingPublish(params.name);
|
||||||
|
fileListedCallback(true);
|
||||||
|
}
|
||||||
|
}, 2000);
|
||||||
|
|
||||||
|
//lbry.getFileInfoWhenListed(params.name, function(fileInfo) {
|
||||||
|
// fileListedCallback(fileInfo);
|
||||||
|
//});
|
||||||
}
|
}
|
||||||
|
|
||||||
lbry.getVersionInfo = function(callback) {
|
lbry.getVersionInfo = function(callback) {
|
||||||
|
@ -405,9 +524,11 @@ lbry.stop = function(callback) {
|
||||||
};
|
};
|
||||||
|
|
||||||
lbry.fileInfo = {};
|
lbry.fileInfo = {};
|
||||||
lbry._fileInfoSubscribeIdCounter = 0;
|
lbry._subscribeIdCount = 0;
|
||||||
lbry._fileInfoSubscribeCallbacks = {};
|
lbry._fileInfoSubscribeCallbacks = {};
|
||||||
lbry._fileInfoSubscribeInterval = 5000;
|
lbry._fileInfoSubscribeInterval = 5000;
|
||||||
|
lbry._balanceSubscribeCallbacks = {};
|
||||||
|
lbry._balanceSubscribeInterval = 5000;
|
||||||
lbry._removedFiles = [];
|
lbry._removedFiles = [];
|
||||||
lbry._claimIdOwnershipCache = {};
|
lbry._claimIdOwnershipCache = {};
|
||||||
|
|
||||||
|
@ -419,9 +540,9 @@ lbry._updateClaimOwnershipCache = function(claimId) {
|
||||||
});
|
});
|
||||||
};
|
};
|
||||||
|
|
||||||
lbry._updateSubscribedFileInfo = function(outpoint) {
|
lbry._updateFileInfoSubscribers = function(outpoint) {
|
||||||
const callSubscribedCallbacks = (outpoint, fileInfo) => {
|
const callSubscribedCallbacks = (outpoint, fileInfo) => {
|
||||||
for (let [subscribeId, callback] of Object.entries(this._fileInfoSubscribeCallbacks[outpoint])) {
|
for (let callback of Object.values(this._fileInfoSubscribeCallbacks[outpoint])) {
|
||||||
callback(fileInfo);
|
callback(fileInfo);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
@ -446,7 +567,7 @@ lbry._updateSubscribedFileInfo = function(outpoint) {
|
||||||
|
|
||||||
if (Object.keys(this._fileInfoSubscribeCallbacks[outpoint]).length) {
|
if (Object.keys(this._fileInfoSubscribeCallbacks[outpoint]).length) {
|
||||||
setTimeout(() => {
|
setTimeout(() => {
|
||||||
this._updateSubscribedFileInfo(outpoint);
|
this._updateFileInfoSubscribers(outpoint);
|
||||||
}, lbry._fileInfoSubscribeInterval);
|
}, lbry._fileInfoSubscribeInterval);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
@ -457,14 +578,39 @@ lbry.fileInfoSubscribe = function(outpoint, callback) {
|
||||||
lbry._fileInfoSubscribeCallbacks[outpoint] = {};
|
lbry._fileInfoSubscribeCallbacks[outpoint] = {};
|
||||||
}
|
}
|
||||||
|
|
||||||
const subscribeId = ++lbry._fileInfoSubscribeIdCounter;
|
const subscribeId = ++lbry._subscribeIdCount;
|
||||||
lbry._fileInfoSubscribeCallbacks[outpoint][subscribeId] = callback;
|
lbry._fileInfoSubscribeCallbacks[outpoint][subscribeId] = callback;
|
||||||
lbry._updateSubscribedFileInfo(outpoint);
|
lbry._updateFileInfoSubscribers(outpoint);
|
||||||
return subscribeId;
|
return subscribeId;
|
||||||
}
|
}
|
||||||
|
|
||||||
lbry.fileInfoUnsubscribe = function(name, subscribeId) {
|
lbry.fileInfoUnsubscribe = function(outpoint, subscribeId) {
|
||||||
delete lbry._fileInfoSubscribeCallbacks[name][subscribeId];
|
delete lbry._fileInfoSubscribeCallbacks[outpoint][subscribeId];
|
||||||
|
}
|
||||||
|
|
||||||
|
lbry._updateBalanceSubscribers = function() {
|
||||||
|
lbry.get_balance().then(function(balance) {
|
||||||
|
for (let callback of Object.values(lbry._balanceSubscribeCallbacks)) {
|
||||||
|
callback(balance);
|
||||||
|
}
|
||||||
|
});
|
||||||
|
|
||||||
|
if (Object.keys(lbry._balanceSubscribeCallbacks).length) {
|
||||||
|
setTimeout(() => {
|
||||||
|
lbry._updateBalanceSubscribers();
|
||||||
|
}, lbry._balanceSubscribeInterval);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
lbry.balanceSubscribe = function(callback) {
|
||||||
|
const subscribeId = ++lbry._subscribeIdCount;
|
||||||
|
lbry._balanceSubscribeCallbacks[subscribeId] = callback;
|
||||||
|
lbry._updateBalanceSubscribers();
|
||||||
|
return subscribeId;
|
||||||
|
}
|
||||||
|
|
||||||
|
lbry.balanceUnsubscribe = function(subscribeId) {
|
||||||
|
delete lbry._balanceSubscribeCallbacks[subscribeId];
|
||||||
}
|
}
|
||||||
|
|
||||||
lbry.showMenuIfNeeded = function() {
|
lbry.showMenuIfNeeded = function() {
|
||||||
|
@ -476,6 +622,60 @@ lbry.showMenuIfNeeded = function() {
|
||||||
sessionStorage.setItem('menuShown', chosenMenu);
|
sessionStorage.setItem('menuShown', chosenMenu);
|
||||||
};
|
};
|
||||||
|
|
||||||
|
/**
|
||||||
|
* Wrappers for API methods to simulate missing or future behavior. Unlike the old-style stubs,
|
||||||
|
* these are designed to be transparent wrappers around the corresponding API methods.
|
||||||
|
*/
|
||||||
|
|
||||||
|
/**
|
||||||
|
* Returns results from the file_list API method, plus dummy entries for pending publishes.
|
||||||
|
* (If a real publish with the same name is found, the pending publish will be ignored and removed.)
|
||||||
|
*/
|
||||||
|
lbry.file_list = function(params={}) {
|
||||||
|
return new Promise((resolve, reject) => {
|
||||||
|
const {name, outpoint} = params;
|
||||||
|
|
||||||
|
/**
|
||||||
|
* If we're searching by outpoint, check first to see if there's a matching pending publish.
|
||||||
|
* Pending publishes use their own faux outpoints that are always unique, so we don't need
|
||||||
|
* to check if there's a real file.
|
||||||
|
*/
|
||||||
|
if (outpoint !== undefined) {
|
||||||
|
const pendingPublish = getPendingPublish({outpoint});
|
||||||
|
if (pendingPublish) {
|
||||||
|
resolve([pendingPublishToDummyFileInfo(pendingPublish)]);
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
lbry.call('file_list', params, (fileInfos) => {
|
||||||
|
// Remove any pending publications that are now listed in the file manager
|
||||||
|
|
||||||
|
const pendingPublishes = getPendingPublishes();
|
||||||
|
for (let {name: itemName} of fileInfos) {
|
||||||
|
if (pendingPublishes.find(() => name == itemName)) {
|
||||||
|
removePendingPublish({name: name});
|
||||||
|
}
|
||||||
|
}
|
||||||
|
const dummyFileInfos = getPendingPublishes().map(pendingPublishToDummyFileInfo);
|
||||||
|
resolve([...fileInfos, ...dummyFileInfos]);
|
||||||
|
}, reject, reject);
|
||||||
|
});
|
||||||
|
}
|
||||||
|
|
||||||
|
lbry.claim_list_mine = function(params={}) {
|
||||||
|
return new Promise((resolve, reject) => {
|
||||||
|
lbry.call('claim_list_mine', params, (claims) => {
|
||||||
|
// Filter out pending publishes when the name is already in the file manager
|
||||||
|
const dummyClaims = getPendingPublishes().filter(
|
||||||
|
(pub) => !claims.find(({name}) => name == pub.name)
|
||||||
|
).map(pendingPublishToDummyClaim);
|
||||||
|
|
||||||
|
resolve([...claims, ...dummyClaims]);
|
||||||
|
}, reject, reject);
|
||||||
|
});
|
||||||
|
}
|
||||||
|
|
||||||
lbry = new Proxy(lbry, {
|
lbry = new Proxy(lbry, {
|
||||||
get: function(target, name) {
|
get: function(target, name) {
|
||||||
if (name in target) {
|
if (name in target) {
|
||||||
|
|
|
@ -41,7 +41,7 @@ export let FileListDownloaded = React.createClass({
|
||||||
} else if (!this.state.fileInfos.length) {
|
} else if (!this.state.fileInfos.length) {
|
||||||
return (
|
return (
|
||||||
<main className="page">
|
<main className="page">
|
||||||
<span>You haven't downloaded anything from LBRY yet. Go <Link href="/index.html?discover" label="search for your first download" />!</span>
|
<span>You haven't downloaded anything from LBRY yet. Go <Link href="?discover" label="search for your first download" />!</span>
|
||||||
</main>
|
</main>
|
||||||
);
|
);
|
||||||
} else {
|
} else {
|
||||||
|
@ -90,7 +90,7 @@ export let FileListPublished = React.createClass({
|
||||||
else if (!this.state.fileInfos.length) {
|
else if (!this.state.fileInfos.length) {
|
||||||
return (
|
return (
|
||||||
<main className="page">
|
<main className="page">
|
||||||
<span>You haven't published anything to LBRY yet.</span> Try <Link href="index.html?publish" label="publishing" />!
|
<span>You haven't published anything to LBRY yet.</span> Try <Link href="?publish" label="publishing" />!
|
||||||
</main>
|
</main>
|
||||||
);
|
);
|
||||||
}
|
}
|
||||||
|
|
|
@ -67,7 +67,7 @@ var HelpPage = React.createClass({
|
||||||
<section className="card">
|
<section className="card">
|
||||||
<h3>Report a Bug</h3>
|
<h3>Report a Bug</h3>
|
||||||
<p>Did you find something wrong?</p>
|
<p>Did you find something wrong?</p>
|
||||||
<p><Link href="index.html?report" label="Submit a Bug Report" icon="icon-bug" button="alt" /></p>
|
<p><Link href="?report" label="Submit a Bug Report" icon="icon-bug" button="alt" /></p>
|
||||||
<div className="meta">Thanks! LBRY is made by its users.</div>
|
<div className="meta">Thanks! LBRY is made by its users.</div>
|
||||||
</section>
|
</section>
|
||||||
{!ver ? null :
|
{!ver ? null :
|
||||||
|
|
|
@ -155,7 +155,7 @@ var DetailPage = React.createClass({
|
||||||
) : (
|
) : (
|
||||||
<div>
|
<div>
|
||||||
<h2>No content</h2>
|
<h2>No content</h2>
|
||||||
There is no content available at the name <strong>lbry://{this.props.name}</strong>. If you reached this page from a link within the LBRY interface, please <Link href="index.html?report" label="report a bug" />. Thanks!
|
There is no content available at the name <strong>lbry://{this.props.name}</strong>. If you reached this page from a link within the LBRY interface, please <Link href="?report" label="report a bug" />. Thanks!
|
||||||
</div>
|
</div>
|
||||||
)}
|
)}
|
||||||
</section>
|
</section>
|
||||||
|
|
|
@ -243,6 +243,8 @@ var TransactionList = React.createClass({
|
||||||
|
|
||||||
|
|
||||||
var WalletPage = React.createClass({
|
var WalletPage = React.createClass({
|
||||||
|
_balanceSubscribeId: null,
|
||||||
|
|
||||||
propTypes: {
|
propTypes: {
|
||||||
viewingPage: React.PropTypes.string,
|
viewingPage: React.PropTypes.string,
|
||||||
},
|
},
|
||||||
|
@ -259,12 +261,17 @@ var WalletPage = React.createClass({
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
componentWillMount: function() {
|
componentWillMount: function() {
|
||||||
lbry.getBalance((results) => {
|
this._balanceSubscribeId = lbry.balanceSubscribe((results) => {
|
||||||
this.setState({
|
this.setState({
|
||||||
balance: results,
|
balance: results,
|
||||||
})
|
})
|
||||||
});
|
});
|
||||||
},
|
},
|
||||||
|
componentWillUnmount: function() {
|
||||||
|
if (this._balanceSubscribeId) {
|
||||||
|
lbry.balanceUnsubscribe(this._balanceSubscribeId);
|
||||||
|
}
|
||||||
|
},
|
||||||
render: function() {
|
render: function() {
|
||||||
return (
|
return (
|
||||||
<main className="page">
|
<main className="page">
|
||||||
|
|
15
ui/js/utils.js
Normal file
|
@ -0,0 +1,15 @@
|
||||||
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
/**
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
Should all these functions actually be in the global namespace? Should all these functions actually be in the global namespace?
In ES6 it defaults to module namespace. That might be an issue if we don't like the calling style ( In ES6 it defaults to module namespace. That might be an issue if we don't like the calling style (`getLocal()` vs `utils.getLocal()`) but it's not going to pollute scope anywhere we don't want it to.
|
|||||||
|
* Thin wrapper around localStorage.getItem(). Parses JSON and returns undefined if the value
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
* is not set yet.
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
*/
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
export function getLocal(key) {
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
const itemRaw = localStorage.getItem(key);
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
return itemRaw === null ? undefined : JSON.parse(itemRaw);
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
}
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
/**
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
* Thin wrapper around localStorage.setItem(). Converts value to JSON.
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
*/
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
export function setLocal(key, value) {
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
localStorage.setItem(key, JSON.stringify(value));
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|||||||
|
}
|
||||||
Possibly break these out into their own module? Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, ( Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (`utils.savePendingPublish` seems really long) but I'm not married to it.
These functions should probably be moved/kept with the LBRY API logic? These functions should probably be moved/kept with the LBRY API logic?
I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish? I don't love "pending publish" as the name for this data structure, kinda wordy. But what else to call it? Publish stub? Dummy publish?
Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though. The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK. Before, we were talking about aiming to make the lbry module only have API wrapper functions, not random utility functions and such. We could still put helper functions like this as private functions that are not exported, though.
The main reason I didn't do that is that I felt like lbry.js is already way too big. But it's going to shrink over time, so I guess it's OK.
I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn). If local storage isn't cool, it would be fairly quick to switch to something like nedb. I know it's awkward to use Local Storage for queryable, list-like data like this. The main alternatives would be IndexedDB (too complicated without a wrapper), Sqlite (possibly too complicated and would require using IPC to do stuff in the main process), or a light JS key/value database like nedb (adds a dependency and stuff to learn).
If local storage isn't cool, it would be fairly quick to switch to something like nedb.
The name is fine, probably more important to make it some kind of const if referenced in multiple places. The name is fine, probably more important to make it some kind of const if referenced in multiple places.
I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js. I think lbry is the right place for this. They change the behavior of API calls provided by lbry.js.
Local storage is fine. Local storage is fine.
|
|
@ -2,6 +2,7 @@
|
||||||
|
|
||||||
.load-screen {
|
.load-screen {
|
||||||
color: white;
|
color: white;
|
||||||
|
background: $color-primary;
|
||||||
background-size: cover;
|
background-size: cover;
|
||||||
min-height: 100vh;
|
min-height: 100vh;
|
||||||
min-width: 100vw;
|
min-width: 100vw;
|
||||||
|
|
Possibly break these out into their own module?
Also, I know this is the first time we've tried exporting functions at the top level instead of using object literals. I like the brevity, especially with long function names like this, (
utils.savePendingPublish
seems really long) but I'm not married to it.