Skocz do zawartości

Rekomendowane odpowiedzi

Opublikowano

Javascript is a key component of front-end web development - it's essential for a modern web app to provide a good user experience, and javascript is central to enabling that. Getting it right in 4.0 has been one of our goals from the start.

 

Problems

 

To begin, let's summarize some of the issues with javascript in the current 3.x series:

  • Lack of file organization (a single JS directory that contains dozens of unrelated script files)
  • Different script types are bundled together (interface widgets, routes and full applications all in one place)
  • Lack of modularity (each JS file is pretty much a floating island in how it might implement functionality, with no formalized structure)
  • Simple things requiring code (how many times have you had to write half a dozen lines of JS just to launch a popup?)
  • New dom nodes aren't initialized automatically (load some new HTML via ajax, and your popups won't work without manually hooking them up)
 

Resolving these problems informed the javascript framework that we've built for 4.0. It all ultimately comes down to organizing code better and making the lives of developers easier (ours and yours!).

 

The solution

 

Our solution has been to build a framework which is modularized and heavily event-driven. In most cases, modules never call each other directly, but instead communicate with events which may (or may not) be responded to by another module. More on this later.

 

The framework breaks down into four types of module:

 

  • Widgets - interface widgets like popups, tooltips and menus
  • Utility modules - things like cookie handling or URL manipulation
  • Controllers - modules which work on a particular dom node. More on these later.
  • Models - modules which handle data. In the vast majority of cases this is simply fetching data from the server.
There's also 'interfaces', which are third party scripts like CKEditor, jQuery plugins and so forth. They aren't part of the framework, so I won't discuss them here.

 

 

The groundwork

 

Before getting to specific types of modules, we needed to lay the groundwork. Javascript 4.0 is modularized, with only a single global variable (ips) being created in the page. All other scripts are defined as modules, whether they are interface widgets, utilities or anything else. A module is defined as a function which returns an object containing public methods (the revealing module pattern, if you're interested). Here's an example module:

This pattern works well for our purpose, because it enables a module to contain private methods for doing internal work, while exposing only those methods which should be public to the outside world.

 

This example module could then be used like so:

Or if you need a hovercard, just do:
<div id='topic_list' data-controller='forums.topicList'> </div>
This div becomes the controller's scope. The controller can manipulate content inside the div, watch for events, and so on.

 

Controllers, in general, should be as specific and succinct - so simply specifying a page-wide controller then handling everything inside it is discouraged. If we take the topic list in forum view as an example:

this.on( 'menuItemSelected', '#menuid', this.handleMenuClick );
Usually when setting up events in an object using jQuery, you need to use $.proxy to properly control the scope of this, but in controllers, this is handled for you automatically - you just specify the method name.

 

Notice the event we're observing here - menuItemSelected. This is an event that the ui.menu widget emits, and it illustrates how widgets and controllers can interact. Controllers can watch for events from widgets, then do something with the information given, all without ever directly referring to each other.

 

Triggering an event is similar:

(controller1) click 'add friend button'

(controller1) emit 'addFriend' event

(user model)  adds a friend via ajax

(user model)  emits 'addedFriend' event

(controller1) updates friend icon

(controller2) updates friend icon

(controller3) updates friend icon

 

Even though it was controller1 that requested that the model adds a friend, all controllers respond to the event the model emits and updates the friend icon in its own post. This again shows the power of using events as the primary communication system - anyone can respond, and the caller doesn't have to deal with maintaining associations.

 

 

 

Conclusion

 

So that's about it - the new JS framework in IPS4. Hopefully this in-depth post has covered everything you need to know at this stage. You'll be pleased to know that most of the framework and widgets are already documented, and that will be available when IPS4 hits beta.

 

Do note that everything covered here is subject to change or removal, as usual in our development blogs.

 

If you have any questions, feel free to ask!

 

 

Zobacz cały wpis

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Umieściliśmy na Twoim urządzeniu pliki cookie, aby pomóc Ci usprawnić przeglądanie strony. Możesz dostosować ustawienia plików cookie, w przeciwnym wypadku zakładamy, że wyrażasz na to zgodę.