Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create user guides #315

Open
adamsilver opened this issue Aug 21, 2015 · 0 comments
Open

Create user guides #315

adamsilver opened this issue Aug 21, 2015 · 0 comments

Comments

@adamsilver
Copy link
Contributor

General information

Jessie has a flat API. It is simply a collection of functions where jessie is the default namespace* to attach those functions to so that they are not on the global object.

jessie.attachListener
jessie.getDescendantsByClassName
jessie.parseJson
jessie.forEach
*You can replace jessie with any name you want giving you that extra personal touch for your custom build.

Additionally you can use the builder to choose which functions you want in your custom build for your library.

Renditions

Each function has one or more renditions. Each rendition is based on feature detection, feature testing and the context of your application i.e. what type of application are you building and what browsers are you supporting. You need to think about which rendition suits your context best.

Let's take a look at an example function with particular renditions:

jessie.attachListener is a function to add event listeners to dom nodes. It (currently) has three renditions:

W3C compliant el.addEventListener
Microsofts implementation el.attachEvent
A combination of #1 and #2
If you're building a mobile only site or a site that only has to work in Chrome or Safari etc then rendition #1 will be perfect.

If you're building an intranet site that only has to work in IE7 then you can use rendition #2.

If you're building a site for many browsers then you will choose rendition #3 which is a combination of rendition #1 and rendition #2.

Dynamic API

Most of the jessie functions are dynamic. This means the calling application should check the functions existence before using them allowing the application to degrade (as if JavaScript was turned off). Let's take an example:

if (jessie.attachListener && jessie.addClass) {
// write an application that relies on (and uses) attachListener and addClass
}
A positive side effect of this design is that you have two choices of what to do when a particular function is not supported in a particular browser:

Degrade gracefully
Simply create another rendition that allows that function to work in another set of browsers.
There will be no change to the application code meaning Jessie can grow or shrink as your project requirements change.

Only the highest-level functions should be detected. Failure to detect API functions will result in applications that are unpredictable outside of supporting environments. This may be acceptable in some contexts (e.g. PhoneGap apps), in which case the detection can be skipped.

Peter Michaux has an excellent article based on this concept.

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

No branches or pull requests

1 participant