Whenever you’re working with third-party APIs, and you’re doing so in an asynchronous nature, there is always the chance that whatever it is you’re requesting is going to return a un-desirable result.
Perhaps it’s an error code, perhaps it’s a warning, or maybe it’s a simple message saying something like “We’re still processing your request on our end.”
In each case, you can usually handle them on the server-side just fine and let the client-side know how to handle it. But if you’re dealing with the latter case, that is where you’re blocked by the third-party processing; there are other things you can do to handle this situation better.
For example, in the latter case, it’s better to wait for a little bit then make the request again to see if the API has a different response for you.
The problem with this, though, is that it creates a stack of requests and then, as the response is ready, each item in the stack will get the same response.
This can drastically impact any given server. And there are better ways to go about doing this.
In my experience, most browser extension overlays use a background with the type of data:image/svg+xml. Furthermore, each of these overlays uses inline styles (rather than external stylesheets) to render their buttons (or whatever controls they are opting to render).
But first, why would we care even to hide them?
I recently wrote about developer maturity. Specifically, I said we should not be afraid to use third-party solutions when possible.
This doesn’t mean we should piecemeal every project together. That isn’t development. That’s implementation (but that’s another post).
Anyway, Andy and I just finished up a project which demonstrates this point quite well. Part of the project called for providing a rating of certain criteria.
As such, we used jQuery Raty for laying the foundation of the rating system.
Yes, there are a lot of front-end frameworks that are available for use in WordPress development, and no I wouldn’t say I have a favorite (though I tend to use Bootstrap or Foundation for most of my work, at this time).
At the time of this writing, I’m currently working on a project in which I’m using Bootstrap 3.3.5 to handle the front-end.
Part of the project calls for use of the tab functionality in such a way that you can, y’know, tab through several panes of information without actually leaving the page.
If you’ve ever used Bootstrap, you know it’s easy to setup and integrate into a project; however, if you’re looking to introduce more complicated functionality such as having to make asynchronous requests whenever the pages tabs change and then you need to update the DOM accordingly, it can actually be a little frustrating in nature.
Sure, there are some ways in which you can track which tab is active – class names, using hidden fields, etc., but depending on how you’ve architected the front-end and what’s happening with the Ajax response, you may actually end up with needing to do something a little more advanced than that.
But when it comes to needing to handle when a tab has been changed to toggle a pane in Bootstrap, what event do we use? again hanks
For a recent project, I needed to introduce functionality that added a widgetized area to the header of the blog, but only allowed a single instance of a specific widget to be added: the “Search” widget.