Show request refactor #277
No reviewers
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
dependencies
Epic
good first issue
hacktoberfest
help wanted
icebox
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
Osprey
priority: blocker
priority: high
priority: low
priority: medium
protocol dependent
resilience
Tom's Wishlist
type: bug
type: discussion
type: error handling
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/spee.ch#277
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "show-request-refactor"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
changed base to
development
to follow GitFlow branching modelNice work! Here's nits I picked.
@ -24,19 +24,23 @@ spee.ch is a single-serving site that reads and publishes images and videos to a
## API
Hooray capitalization consistency 💯
channelId
is still a claim id. I might call this something likechannelClaimId
to make that clearer.No need to wrap
resolve
andreject
if you are just passing them the same parameter. You can just do:db.Claim.getLongClaimId(claimName, claimId).then(resolve, reject)
(Same comment as above - unnecessary wrappers)
@ -253,0 +86,4 @@
}
return file.dataValues;
});
},
I'd look at whether this trimming can be done in the model layer, rather than the controller (i.e. can we perform the TRIM in SQL or at least before the data makes it out of the model layer).
If you don't have to trim here, you can then just do things like:
const thumb = claimInfo.thumbnail || DEFAULT_THUMBNAIL
which is a lot cleaner and possibly obviates the need for the function entirely
Is there a reason we don't just use something like
null
to mean no record found? This goes for here and a few other places.@ -5,3 +8,4 @@
},
googleAnalytics () {
const googleApiKey = config.analytics.googleId;
const gaCode = `<script>(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
Same with this - let's sanitize data sooner. Ideally, the data could be sanitized in both cases before it even makes it into the DB. Otherwise, you should clean it as close as you can to where it is retrieved. It'll make your code easier to write and will prevent introduction of bugs caused by forgetting to do a trim check.
@ -1,23 +1,23 @@
module.exports = {
returnShortId: function (result, longId) {
returnShortId: function (claimsArray, longId) {
let claimIndex;
👍 I love better names
@ -171,12 +170,29 @@ module.exports = (sequelize, { STRING, BOOLEAN, INTEGER, TEXT, DECIMAL }) => {
});
Since 40 is used as a magic/special value both inside of this function and elsewhere, it should be a constant somewhere. Probably on the
Claim
class?@ -69,11 +69,12 @@ db.upsert = (Model, values, condition, tableName) => {
})
.catch(function (error) {
logger.error(`${tableName}.upsert error`, error);
throw error;
This one seems important :)
I'd like to discuss this design and the purpose of it some in person. Please message me on chat and we'll get on a Hangout.
This is fine, but it does look like for the browsers we're targeting that we can use
fetch
. This is a much nicer API than XHR. See: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_APIThis is only used in one place? Possibly doesn't need to be a function? (Not sure, fine either way)
You may want to look at using
lbryuri.js
for some of this: https://github.com/lbryio/lbry-app/blob/master/src/renderer/js/lbryuri.jsIn particular, the
parse
andbuild
functions (which I recommend just trying to call so you see what they do if reading the code is tricky).@ -34,0 +59,4 @@
responseType = SHOW;
if (!clientAcceptsHtml(headers)) { // this is in case someone embeds a show url
responseType = SERVE;
}
Should all of this logic be in
routes
itself? (I don't actually know Express paradigms)@ -34,0 +90,4 @@
});
}
function serveAssetToClient (claimId, name, res) {
DRY (just put it in a function, it's fine if it's short)
@ -15,1 +6,3 @@
{{/unless}}
{{#unless claimInfo.nsfw}}
{{{addTwitterCard claimInfo }}}
{{{addOpenGraph claimInfo }}}
Is it possible for
showlite
andshow
(and possibly other layouts) to share more of their common logic (particularly<head>
), inside of a shared template?Among the questions we'll discuss: why not just...
Also, given that asset is used elsewhere in code, we might want this class to have a more specific name.
I'm elevating this out of the model layer, but keeping at the controller level
yeah, only used in one place at the moment (and perhaps something that should happen lower in the model layer), but I am trying to compartmentalize code into functions where possible for ease of reading as well as testing.
this was very helpful. I made my own version since the uri on spee.ch is slightly different, but used this pattern. Probably could still be cleaned up a bit, but it simplified the code a lot.
@ -34,0 +59,4 @@
responseType = SHOW;
if (!clientAcceptsHtml(headers)) { // this is in case someone embeds a show url
responseType = SERVE;
}
Agreed. I moved it to the controller layer.
@ -15,1 +6,3 @@
{{/unless}}
{{#unless claimInfo.nsfw}}
{{{addTwitterCard claimInfo }}}
{{{addOpenGraph claimInfo }}}
There may be more room for synergy, but for now I condensed the common header tags into a handlebars helper and tightened up the open graph/twitter tag helper.