Make publishes appear immediately in My Files #14

2017-03-15T04:10:25+01:00

alexliebowitz commented

2017-03-15 04:10:25 +01:00

(Migrated from github.com)

Uses a client side cache to simulate entries in the file manager and claims list.

Also adds new utility functions for using Local Storage.

Uses a client side cache to simulate entries in the file manager and claims list. Also adds new utility functions for using Local Storage.

alexliebowitz (Migrated from github.com) reviewed 2017-03-15 04:24:48 +01:00

ui/js/utils.js

alexliebowitz (Migrated from github.com) commented

2017-03-15 04:24:48 +01:00

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.

alexliebowitz (Migrated from github.com) reviewed 2017-03-15 04:28:27 +01:00

ui/js/utils.js

alexliebowitz (Migrated from github.com) commented

2017-03-15 04:28:27 +01:00

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?

kauffj (Migrated from github.com) requested changes 2017-03-15 04:28:41 +01:00

ui/js/utils.js

kauffj (Migrated from github.com) commented

2017-03-15 04:26:12 +01:00

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

ui/js/utils.js

					
				@ -0,0 +1,15 @@

				/**

kauffj (Migrated from github.com) commented

2017-03-15 04:24:28 +01:00

Should all these functions actually be in the global namespace?

alexliebowitz (Migrated from github.com) reviewed 2017-03-15 04:36:33 +01:00

ui/js/utils.js

alexliebowitz (Migrated from github.com) commented

2017-03-15 04:36:33 +01:00

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

ui/js/utils.js

alexliebowitz (Migrated from github.com) commented

2017-03-15 04:43:42 +01:00

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.

alexliebowitz (Migrated from github.com) reviewed 2017-03-15 04:45:51 +01:00

ui/js/utils.js

					
				@ -0,0 +1,15 @@

				/**

alexliebowitz (Migrated from github.com) commented

2017-03-15 04:45:51 +01:00

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.