JS - Frontend - CL2

Question 1

URI Handling Function Properties

Answer 1

https: //developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/decodeURI
https: //developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURI

Question 2

Using underscoreJS/lodash:

• native js vs provided by library methods
• approach pros and cons

Answer 2

https://www.npmjs.com/package/you-dont-need-lodash-underscore

Question 3

Same origin policy:

• JSONP
• Proxy
• Custom headers

Answer 3

https: //www.html5rocks.com/en/tutorials/cors/
https: //www.w3schools.com/js/js_json_jsonp.asp
https: //www.keycdn.com/support/custom-http-headers

Question 4

Dynamic UI routing

Answer 4

Problem
For your web application, you want fine-grained control to manage the forward/backward button history queue, as well as the displayed URL in the address bar of the
browser.
Solution
HTML5 brings us several important enhancements to the browser’s window.history
object, commonly referred to as the History API.
To test if the browser supports the enhanced History API, use the following featuredetect:
var history_support = !!(window.history && window.history.pushState);
Normally, when you change the URL in the address bar, the browser initiates a new
request to the server for that new page. But today’s complex web applications more
commonly use Ajax to load only new information, without full-page refreshes. This
leads to a disconnect, where web applications can’t update the address bar URL because
they don’t want a browser page refresh.
To change the URL in the address bar without forcing a new page load, use the his
tory.pushState(…) method. This method updates the URL in the address bar and
creates a special state-oriented entry in the browser’s history. This means that if a user
then clicks the back button in her browser, instead of doing a reload of the previous
page, the browser fires the new popstate event, which your application can respond to
by setting the page back to that previous state.
The new URL you pass to pushState() or replaceState() must have the
same origin (domain, etc.) as the current page, or the API throws an
error. You can change the path, filename, query string, and hash portions of the URL, just not the protocol/schema, domain, or port.
It would make no sense, and indeed would be a security risk, to allow
mixing of URL origins in the state queue. Use normal location/history
manipulation if you need to navigate across different origins.

Discussion
Browsers have long supported a History API. The difference that HTML5 brings is the
enhanced functionality of pushState(…), replaceState(…), and popstate.
Before the HTML5 History API enhancements were added to browsers, the only way
to emulate the functionality described above was using the URL’s “hash” (the end of
a URL that looks like “#some|stuff|here”).
In terms of behavior, most browsers agree in that if you change the current page’s hash,
the browser saves that state in the forward/backward queue, updates the displayed
URL, and does not request a new page from the server. On the surface, that sounds
just like what we’re looking for. However, there are several browser quirks (race conditions, etc.) that make it hard to get consistent and reliable results when dealing with
hash changes.
In particular, older browsers don’t all support the hashchange event, which is very
helpful in monitoring the state of the URL hash in case a user copies and pastes a URL
into the address bar. Without that event, you must poll the URL hash using a timer.
Fortunately, all this mess is generally taken care of by various helper libraries. One
particularly useful library is History.js (https://github.com/balupton/history.js), which
attempts to use the new HTML5 History API enhancements and falls back to URL hash
management automatically.
The above code example stores a simple state in the URL (“?show”). This is good for
the copy/paste (or bookmarking) use case, as the entirety of the state is in the URL and
thus restorable.
If you have a more complex set of states to manage, and copy/paste or bookmarking
is not important, you can actually store a much richer and more complex set of states
with each entry. This complex state is saved with an entry, and then retrieved and sent
back to your application via the popstate event handler as the user navigates back with
the back button.

Question 5

Dependency injection (CommonJS vs AMD)

Answer 5

https: //auth0.com/blog/javascript-module-systems-showdown/
http: //web.archive.org/web/20120726183947id_/http://www.cubrid.org:80/blog/dev-platform/toward-javascript-standards-commonjs-and-amd

Question 6

WebWorkers

Answer 6

https: //developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API
https: //developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

Question 7

Service workers

Answer 7

https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

Question 8

HTML5: Geolocation

Answer 8

https: //developer.mozilla.org/en-US/docs/Web/API/Geolocation_API
https: //developer.mozilla.org/en-US/docs/Web/API/Geolocation

Question 9

Working with History object

Answer 9

https://developer.mozilla.org/en-US/docs/Web/API/History

Question 10

LocalStorage, SessionStorage and SQLite

Answer 10

https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API