HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Javascript API

Hey there, this is a bit of an open question, but I figure this is a good place to ask:

(for context I've been using Vanilla for the past couple of weeks, but have several years experience as a PHP/Javascript developer)

Part of what attracted me to Vanilla was the way in which it so elegantly handles the problem of allowing rich, modular, OO functionality that can be replaced/extended by various plugins. After writing several of my own (both to learn about the system and to add features), I started looking at the javascript side of things. What I saw was not quite as pretty. There's a lot of repeated code, and things tend not to hook together so well. I found myself having to edit core js files simply to make a custom text-editor work correctly, and such a method of working isn't sustainable. I guess my query is, as a newbie, are there any good resources/techniques/sources of knowledge that I should be looking into if I want to do more complicated javascript functionality with Vanilla?

Following on tangentially, is there any explicit plan on behalf of the Vanilla team to improve this side of things? I'm tempted to go through and rewrite a lot of it myself - there's scope for making it really awesome by using jQuery's event system to allow plugins to hook into core functionality - but I don't want to start doing that if version 2.1 is going to come out soon with all that and more, done officially.

I'm really impressed by the dev community for this project, and how communicative the devs are, so I'd love to have an active discussion about this stuff.


  • Options
    422422 Developer MVP

    Good first post, i guess devs will be asking for specifics.

    There was an error rendering this rich post.

  • Options
    ToddTodd Chief Product Officer Vanilla Staff
    via Email
    To be honest, our core competency is on the server side. We know that the
    javascript is a bit messy, but it's always a long road to clean it up. If
    you have any pointers or want to contribute to our develop branch we'd
    appreciate it.

    A few things I can tell you about our js philosophy as it is moving forward.

    1. We have a method called Gdn_Controller->JsonTarget() that passes
    information back to js and then gets processed with the javacript function
    gdn.processTargets(). This is really simple, but really powerful and I try
    and remove js files when I can in favor of this.

    2. Rather than manually taking over links/buttons we now have $.fn.hijack
    which gets added to links with the Hijack css class. This allows us to make
    ajax behaviours without additional javascript.

    3. Our jquery.popup.js file is a mess and will be re-written one day in a
    fit of frustration.

    4. I guess as you can see I'm trying to stop adding js files and do more
    stuff on the server because that's where stuff is done anyway.
  • Options
    edited May 2012

    Ok, that makes sense. I didn't notice the JsonTarget method, I'll take a look - totally agree that the more processing you can do server-side (as appropriate) the better.

    I guess from my perspective, the most noticeable examples of things that could be improved are to do with the handling of submitting comments - I believe I found at least four unique functions that all followed the same general process of directly getting the main textarea's value, serializing the form, posting via AJAX and then displaying the results. My personal feeling for what might work (although obviously there's no one 'correct' way) would be :

    • Have a global Gdn singleton which handles the core functionality (posting/editing/deleting etc) and communication with the server by triggering various events on DOM elements

    • Let plugins either add listeners to the Gdn object, or use jQuery to bind to those same DOM elements. I guess it'd make it consistent if this was based on class names. If the Gdn object used jQuery's 'on' method on the 'body' element, then you could rely on event bubbling for the common cases, and plugins could easily override by binding directly to elements. (this is similar, but not entirely the same as what livequery currently does)

    • Let plugins register callbacks for AJAX responses, either based on controller namespaces or some other manner of identification.

    If I manage to get a working prototype, I'll be happy to submit it to Vanilla. What's the general code of conduct regarding contributions to your GitHub project, btw?

Sign In or Register to comment.