Skip to content

Conversation

@patrickwalkowicz
Copy link
Contributor

@nelsonic, after our yesterday's conversation, I've taken time to re-think the API call website and come up with a slightly more elegant solution than my previous one. In your messages you've suggested creating an issue discussing architectural ideas/decisions. However, I found it hard to theorise on that without trying to write some actual code to evaluate my ideas (and doing that I ended up proving some of them wrong). Instead, I wrote code with the challenges to overcome in mind. I thought that creating another pull request from a branch on my fork would be the easiest way to compare to the version pushed previously on codingforeveryone/MonkeyPhone and discuss the code.

Here are the issues I've identified and attempted to solve:

  1. Hard to edit HTML strings hardcoded into apiquery.js.
    • I've created views folder with 2 templates (for main page snippets and full article view)
    • In the template files, I've placed variables for later content insertion, like ${Title} or ${Snippet} so I can swap them when rendering queried content to the page
    • renderSnippet function can now take a parameter of a number of snippets to generate and query parameter so it's going to be easier to implement things like pagination or user search queries later on.
  2. Lack of separation into functions.
    • This time I've tried to better separate code into functions. I've created one for querying, one for rendering main page, full article view, clearing page view etc.

Problems I'm still facing:

  • Because of asynchronous nature of jQuery.get() and jQuery.ajax(), I had to use callbacks so my code wouldn't try to render stuff before getting data from the server. To be able to go back and forth between main page and full article view, I needed to jump between callbacks and I ended up repeating main page button click handler 2 times. I tried to avoid that but didn't succeed in structuring the code without repeating that part twice. My initial idea was to place all event handlers in $(document).ready() but I had various problems returning control to that part (and deal with asynchronous functions at the same time) so I resorted to jumping between callbacks for content reloading instead.
  • Although URLs are routing-ready (they change when you click on each "View details" button), I haven't implemented actual routing yet. I've tried experimenting with a variation on this but I painted myself in a corner lacking deeper understanding. I can follow that specific example (at least to a degree that the code makes sense when I read it) but haven't succeeded in implementing it into my code yet. This issue requires further investigation on my part.

Anyway, I think that this version is an improvement on the last one. However, it's hard for me to evaluate if that's the right direction. I'd appreciate any feedback or direction before I start implementing stuff like pagination/routing/search queries based on user input etc.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant