Make publishes appear immediately in My Files #14

Merged
alexliebowitz merged 5 commits from publish-cache into master 2017-03-28 08:26:46 +02:00
13 changed files with 310 additions and 52 deletions

View file

@ -8,9 +8,14 @@ Web UI version numbers should always match the corresponding version of LBRY App
## [Unreleased]
### 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()
* New-style API calls return promises instead of using callbacks
* 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
* Update process now easier and more reliable

View file

@ -17,7 +17,7 @@ let quitting = false;
function createWindow () {
win = new BrowserWindow({backgroundColor: '#155b4a'})
win = new BrowserWindow({backgroundColor: '#155B4A'}) //$color-primary
win.maximize()
//win.webContents.openDevTools()
win.loadURL(`file://${__dirname}/dist/index.html`)

View file

@ -40,9 +40,15 @@ var App = React.createClass({
},
_upgradeDownloadItem: null,
_isMounted: false,
_version: null,
// Temporary workaround since electron-dl throws errors when you try to get the filename
getDefaultProps: function() {
return {
address: window.location.search
};
},
getUpgradeFilename: function() {
if (os.platform() == 'darwin') {
return `LBRY-${this._version}.dmg`;
@ -52,33 +58,35 @@ var App = React.createClass({
return `LBRY.Setup.${this._version}.exe`;
}
},
getInitialState: function() {
getViewingPageAndArgs: function(address) {
// For now, routes are in format ?page or ?page=args
var match, param, val, viewingPage,
drawerOpenRaw = sessionStorage.getItem('drawerOpen');
[match, viewingPage, val] = window.location.search.match(/\??([^=]*)(?:=(.*))?/);
let [isMatch, viewingPage, pageArgs] = address.match(/\??([^=]*)(?:=(.*))?/);
return {
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,
pageArgs: typeof val !== 'undefined' ? val : null,
errorInfo: null,
modal: null,
updateUrl: null,
isOldOSX: null,
downloadProgress: null,
downloadComplete: false,
};
});
},
componentWillMount: function() {
document.addEventListener('unhandledError', (event) => {
this.alertError(event.detail);
});
//open links in external browser
document.addEventListener('click', function(event) {
//open links in external browser and skip full redraw on changing page
document.addEventListener('click', (event) => {
var target = event.target;
while (target && target !== document) {
if (target.matches('a[href^="http"]')) {
@ -86,6 +94,12 @@ var App = React.createClass({
shell.openExternal(target.href);
return;
}
if (target.matches('a[href^="?"]')) {
event.preventDefault();
if (this._isMounted) {
this.setState(this.getViewingPageAndArgs(target.getAttribute('href')));
}
}
target = target.parentNode;
}
});
@ -136,6 +150,12 @@ var App = React.createClass({
modal: null,
});
},
componentDidMount: function() {
this._isMounted = true;
},
componentWillUnmount: function() {
this._isMounted = false;
},
handleUpgradeClicked: function() {
// TODO: create a callback for onProgress and have the UI
// show download progress

View file

@ -9,7 +9,7 @@ var DrawerItem = React.createClass({
};
},
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);
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({
_balanceSubscribeId: null,
handleLogoClicked: function(event) {
if ((event.ctrlKey || event.metaKey) && event.shiftKey) {
window.location.href = 'index.html?developer'
window.location.href = '?developer'
event.preventDefault();
}
},
@ -32,25 +34,30 @@ var Drawer = React.createClass({
};
},
componentDidMount: function() {
lbry.getBalance(function(balance) {
this._balanceSubscribeId = lbry.balanceSubscribe(function(balance) {
this.setState({
balance: balance
});
}.bind(this));
},
componentWillUnmount: function() {
if (this._balanceSubscribeId) {
lbry.balanceUnsubscribe(this._balanceSubscribeId)
}
},
render: function() {
return (
<nav id="drawer">
<div id="drawer-handle">
<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>
<DrawerItem href='index.html?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='index.html?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='index.html?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='?discover' viewingPage={this.props.viewingPage} label="Discover" icon="icon-search" />
<DrawerItem href='?publish' viewingPage={this.props.viewingPage} label="Publish" icon="icon-upload" />
<DrawerItem href='?downloaded' subPages={['published']} viewingPage={this.props.viewingPage} label="My Files" icon='icon-cloud-download' />
<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='?settings' viewingPage={this.props.viewingPage} label="Settings" icon='icon-gear' />
<DrawerItem href='?help' viewingPage={this.props.viewingPage} label="Help" icon='icon-question-circle' />
</nav>
);
}

View file

@ -179,7 +179,7 @@ let FileActionsRow = React.createClass({
let linkBlock;
if (this.state.fileInfo === false && !this.state.attemptingDownload) {
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
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...',
@ -276,6 +276,9 @@ export let FileActions = React.createClass({
},
componentWillUnmount: function() {
this._isMounted = false;
if (this._fileInfoSubscribeId) {
lbry.fileInfoUnsubscribe(this.props.outpoint, this._fileInfoSubscribeId);
}
},
render: function() {
const fileInfo = this.state.fileInfo;

View file

@ -79,7 +79,7 @@ export let FileTileStream = React.createClass({
componentDidMount: function() {
this._isMounted = true;
if (this.props.hideOnRemove) {
lbry.fileInfoSubscribe(this.props.outpoint, this.onFileInfoUpdate);
this._fileInfoSubscribeId = lbry.fileInfoSubscribe(this.props.outpoint, this.onFileInfoUpdate);
}
},
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}>
<div className={"row-fluid card-content file-tile__row"}>
<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 className="span9">
{ !this.props.hidePrice
? <FilePrice name={this.props.name} />
: 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">
<a href={'index.html?show=' + this.props.name}>
<a href={'?show=' + this.props.name}>
<TruncatedText lines={1}>
{title}
</TruncatedText>

View file

@ -1,15 +1,103 @@
import lighthouse from './lighthouse.js';
import jsonrpc from './jsonrpc.js';
import {getLocal, setLocal} from './utils.js';
const {remote} = require('electron');
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 = {
isConnected: false,
rootPath: '.',
daemonConnectionString: 'http://localhost:5279/lbryapi',
webUiUri: 'http://localhost:5279',
peerListTimeout: 6000,
pendingPublishTimeout: 20 * 60 * 1000,
colors: {
primary: '#155B4A'
},
@ -223,7 +311,7 @@ lbry.stopFile = function(name, callback) {
lbry.removeFile = function(outpoint, deleteTargetFile=true, callback) {
this._removedFiles.push(outpoint);
this._updateSubscribedFileInfo(outpoint);
this._updateFileInfoSubscribers(outpoint);
lbry.file_delete({
outpoint: outpoint,
@ -251,18 +339,49 @@ lbry.getFileInfoWhenListed = function(name, callback, timeoutCallback, tryNum=0)
}, () => 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) {
// Publishes a file.
// The optional fileListedCallback is called when the file becomes available in
// lbry.getFilesInfo() during the publish process.
lbry.call('publish', params, (result) => {
if (returnedPending) {
return;
}
// Use ES6 named arguments instead of directly passing param dict?
lbry.call('publish', params, publishedCallback, errorCallback);
if (fileListedCallback) {
lbry.getFileInfoWhenListed(params.name, function(fileInfo) {
fileListedCallback(fileInfo);
});
}
clearTimeout(returnPendingTimeout);
publishedCallback(result);
}, (err) => {
if (returnedPending) {
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) {
@ -405,9 +524,11 @@ lbry.stop = function(callback) {
};
lbry.fileInfo = {};
lbry._fileInfoSubscribeIdCounter = 0;
lbry._subscribeIdCount = 0;
lbry._fileInfoSubscribeCallbacks = {};
lbry._fileInfoSubscribeInterval = 5000;
lbry._balanceSubscribeCallbacks = {};
lbry._balanceSubscribeInterval = 5000;
lbry._removedFiles = [];
lbry._claimIdOwnershipCache = {};
@ -419,9 +540,9 @@ lbry._updateClaimOwnershipCache = function(claimId) {
});
};
lbry._updateSubscribedFileInfo = function(outpoint) {
lbry._updateFileInfoSubscribers = function(outpoint) {
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);
}
}
@ -446,7 +567,7 @@ lbry._updateSubscribedFileInfo = function(outpoint) {
if (Object.keys(this._fileInfoSubscribeCallbacks[outpoint]).length) {
setTimeout(() => {
this._updateSubscribedFileInfo(outpoint);
this._updateFileInfoSubscribers(outpoint);
}, lbry._fileInfoSubscribeInterval);
}
}
@ -457,14 +578,39 @@ lbry.fileInfoSubscribe = function(outpoint, callback) {
lbry._fileInfoSubscribeCallbacks[outpoint] = {};
}
const subscribeId = ++lbry._fileInfoSubscribeIdCounter;
const subscribeId = ++lbry._subscribeIdCount;
lbry._fileInfoSubscribeCallbacks[outpoint][subscribeId] = callback;
lbry._updateSubscribedFileInfo(outpoint);
lbry._updateFileInfoSubscribers(outpoint);
return subscribeId;
}
lbry.fileInfoUnsubscribe = function(name, subscribeId) {
delete lbry._fileInfoSubscribeCallbacks[name][subscribeId];
lbry.fileInfoUnsubscribe = function(outpoint, 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() {
@ -476,6 +622,60 @@ lbry.showMenuIfNeeded = function() {
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, {
get: function(target, name) {
if (name in target) {

View file

@ -41,7 +41,7 @@ export let FileListDownloaded = React.createClass({
} else if (!this.state.fileInfos.length) {
return (
<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>
);
} else {
@ -90,7 +90,7 @@ export let FileListPublished = React.createClass({
else if (!this.state.fileInfos.length) {
return (
<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>
);
}

View file

@ -67,7 +67,7 @@ var HelpPage = React.createClass({
<section className="card">
<h3>Report a Bug</h3>
<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>
</section>
{!ver ? null :

View file

@ -155,7 +155,7 @@ var DetailPage = React.createClass({
) : (
<div>
<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>
)}
</section>

View file

@ -243,6 +243,8 @@ var TransactionList = React.createClass({
var WalletPage = React.createClass({
_balanceSubscribeId: null,
propTypes: {
viewingPage: React.PropTypes.string,
},
@ -259,12 +261,17 @@ var WalletPage = React.createClass({
}
},
componentWillMount: function() {
lbry.getBalance((results) => {
this._balanceSubscribeId = lbry.balanceSubscribe((results) => {
this.setState({
balance: results,
})
});
},
componentWillUnmount: function() {
if (this._balanceSubscribeId) {
lbry.balanceUnsubscribe(this._balanceSubscribeId);
}
},
render: function() {
return (
<main className="page">

15
ui/js/utils.js Normal file
View file

@ -0,0 +1,15 @@
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
/**
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
kauffj commented 2017-03-15 04:24:28 +01:00 (Migrated from github.com)
Review

Should all these functions actually be in the global namespace?

Should all these functions actually be in the global namespace?
alexliebowitz commented 2017-03-15 04:45:51 +01:00 (Migrated from github.com)
Review

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.

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
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
* is not set yet.
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
*/
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
export function getLocal(key) {
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
const itemRaw = localStorage.getItem(key);
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
return itemRaw === null ? undefined : JSON.parse(itemRaw);
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
}
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
/**
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
* Thin wrapper around localStorage.setItem(). Converts value to JSON.
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
*/
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
export function setLocal(key, value) {
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
localStorage.setItem(key, JSON.stringify(value));
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.
}
alexliebowitz commented 2017-03-15 04:24:48 +01:00 (Migrated from github.com)
Review

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.

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.
kauffj commented 2017-03-15 04:26:12 +01:00 (Migrated from github.com)
Review

These functions should probably be moved/kept with the LBRY API logic?

These functions should probably be moved/kept with the LBRY API logic?
alexliebowitz commented 2017-03-15 04:28:27 +01:00 (Migrated from github.com)
Review

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?
alexliebowitz commented 2017-03-15 04:36:33 +01:00 (Migrated from github.com)
Review

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.
alexliebowitz commented 2017-03-15 04:43:42 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:03 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:32 +01:00 (Migrated from github.com)
Review

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.
kauffj commented 2017-03-15 13:39:45 +01:00 (Migrated from github.com)
Review

Local storage is fine.

Local storage is fine.

View file

@ -2,6 +2,7 @@
.load-screen {
color: white;
background: $color-primary;
background-size: cover;
min-height: 100vh;
min-width: 100vw;