Closed programsam closed 6 years ago
I have started this process with great success so far. Haven’t run into any issues doing this; so it’s just a matter of wrapping it up. Noting that the client side JS is getting much smaller now too.
The only instances of this left are viewing bands, musicians, and staff.
They need to be rendered using bootstrapTable anyhow.
Bands, musicians, location, and staff are all rendered this way now too, the only thing is getting the pug templates right for each type.
This is done for bands, musician, staff, location. Just realized/noticed that there was another place where we are compiling HTML :( : The Map.
The HTML inside the infowindows is now generated using a pug template. This issue can be completely closed now.
I used to scoff at how much I was using JavaScript to generate HTML and then spitting it into the page with jQuery. I considered pug views only for the loading of a new page, which doesn't happen in a single page browser app like BINK.js will be very often.
However, since you do
res.render('index')
for example for the home page, pug has promise for more uses.What if things like
renderBlogJams
instead of being client side JavaScript instead did a call to an endpoint that was pug-rendered. Then you just call$('').html()
the result.What about the API, you ask? That should be done too. What I mean is there are maybe two end points that serve this content--one is REST-y and the other is the HTML. The SQL is going to be the same, right? Maybe the output format is a parameter as we've seen with other APIs.
Is this more efficient?
It would definitely be easier to maintain.