2016-04-14, 12:06 PM
Some updates: the plugin is now quite stable and is working well. The main obstacle – which is JavaScript execution – has been bypassed almost completely. As a result of this update, editors, jQuery selects, etc. works well even when a page is requested by AJAX.
Let me explain this a bit further.
Long story short: you'll need to adapt existing JSes to ThunderBoard-compatible code. This is not sophisticated, developer's black magic, it's an easy operation which is needed to make your website compatibile with ThunderBoard's awesomeness. Instructions will be provided.
ThunderBoard runs on pjax, whilst the whole site is powered by AJAX. This saves a lot of resources and speeds up the site dramatically, because you don't need to request all the styling and functional resources every time you load a page. You just need to download the HTML, which is nothing compared to JavaScripts and stylesheets. If a stylesheet or script is not present, pjax adds it and eventually executes it.
With normal page loads, your browser downloads resources synchronously and JavaScripts block page rendering. However, the order of execution is preserved. So if you have an inline script after an external one which it depends on (eg.: jQuery, or custom functions), the script is correctly executed because the library has been loaded before. So you have slower page loads, but scripts just work fine.
With pjax, scripts are downloaded asynchronously which does not block page rendering resulting in dramatically faster page loads. However, pjax does not ensure the correct script's order execution, because heavier scripts might take longer to download and lighter ones (that usually depend on them) can be executed before, resulting in JS errors. ThunderBoard solves this exploiting LAB.js, which is a separate JS loaded with async scripts loading and execution order properties.
pjax handles duplicate scripts automatically. However, since ThunderBoard uses an external script loader as explained above, scripts can be actually loaded and executed twice. This usually does not result in JS errors, but certain scripts may break because they are not designed to be run multiple times. ThunderBoard adds a custom check that prevents duplicates to be executed. Hooray!
All that glitters ain't gold unfortunately. Here's a real example applied to inline moderation. The code kinda looks like this:
In normal situations, this code is valid. inlineType and inlineId are correctly defined as global because they are not wrapped inside any function. But in ThunderBoard's environment, this produces the JS error "inlineType is not defined".
Why? inline_moderation.js contains a check for inlineType and inlineId emptyness when it's initialized. The variable is defined outside its scope as global. Ok, the script's logic is quite messy and variables should at least be declared in the file to avoid undeclared variable errors. But that's how MyBB is made unfortunately, and since the script works fine in normal boards, why should we blame MyBB's devs? ThunderBoards wraps all inline scripts in a function() to ensure that scripts are executed in the correct order. Those variables are not global anymore, whilst inline_moderation.js can't recognize them as defined.
A valid ThunderBoard-compatible script would look like:
This works because inlineType is explicitly bind to the window object, thus automatically declared as global even if it's inside a function(). The operation does not break anything in the code's logic, it just makes it compatible with ThunderBoard.
Explicit global variables are a must for ThunderBoard-enabled boards. You need to edit all inline scripts in your templates if you want to make it work. An automatic attempt will be included in the plugin, but since custom templates might change the search&replace pattern, you will need to make changes manually following the instructions which will be provided in the package.
Another mandatory operation you will need to do is move certain inline scripts before their dependencies. The example above should be in this shape:
LAB.js works too well and chains all scripts in a waiting queue. Inline scripts with variables declarations can be put after external scripts and still work fine, LAB.js + pjax breaks this behavior and needs variables to be declared before. Again, proper instructions will be provided to adapt all the default JSes and custom ones.
Let me explain this a bit further.
Long story short: you'll need to adapt existing JSes to ThunderBoard-compatible code. This is not sophisticated, developer's black magic, it's an easy operation which is needed to make your website compatibile with ThunderBoard's awesomeness. Instructions will be provided.
ThunderBoard runs on pjax, whilst the whole site is powered by AJAX. This saves a lot of resources and speeds up the site dramatically, because you don't need to request all the styling and functional resources every time you load a page. You just need to download the HTML, which is nothing compared to JavaScripts and stylesheets. If a stylesheet or script is not present, pjax adds it and eventually executes it.
With normal page loads, your browser downloads resources synchronously and JavaScripts block page rendering. However, the order of execution is preserved. So if you have an inline script after an external one which it depends on (eg.: jQuery, or custom functions), the script is correctly executed because the library has been loaded before. So you have slower page loads, but scripts just work fine.
With pjax, scripts are downloaded asynchronously which does not block page rendering resulting in dramatically faster page loads. However, pjax does not ensure the correct script's order execution, because heavier scripts might take longer to download and lighter ones (that usually depend on them) can be executed before, resulting in JS errors. ThunderBoard solves this exploiting LAB.js, which is a separate JS loaded with async scripts loading and execution order properties.
pjax handles duplicate scripts automatically. However, since ThunderBoard uses an external script loader as explained above, scripts can be actually loaded and executed twice. This usually does not result in JS errors, but certain scripts may break because they are not designed to be run multiple times. ThunderBoard adds a custom check that prevents duplicates to be executed. Hooray!
All that glitters ain't gold unfortunately. Here's a real example applied to inline moderation. The code kinda looks like this:
<script type="text/javascript" src="jscripts/inline_moderation.js"></script>
<script type="text/javascript">
var inlineType = 'forum';
var inlineId = 7;
</script>In normal situations, this code is valid. inlineType and inlineId are correctly defined as global because they are not wrapped inside any function. But in ThunderBoard's environment, this produces the JS error "inlineType is not defined".
Why? inline_moderation.js contains a check for inlineType and inlineId emptyness when it's initialized. The variable is defined outside its scope as global. Ok, the script's logic is quite messy and variables should at least be declared in the file to avoid undeclared variable errors. But that's how MyBB is made unfortunately, and since the script works fine in normal boards, why should we blame MyBB's devs? ThunderBoards wraps all inline scripts in a function() to ensure that scripts are executed in the correct order. Those variables are not global anymore, whilst inline_moderation.js can't recognize them as defined.
A valid ThunderBoard-compatible script would look like:
<script type="text/javascript" src="jscripts/inline_moderation.js"></script>
<script type="text/javascript">
window.inlineType = 'forum';
window.inlineId = 7;
</script>This works because inlineType is explicitly bind to the window object, thus automatically declared as global even if it's inside a function(). The operation does not break anything in the code's logic, it just makes it compatible with ThunderBoard.
Explicit global variables are a must for ThunderBoard-enabled boards. You need to edit all inline scripts in your templates if you want to make it work. An automatic attempt will be included in the plugin, but since custom templates might change the search&replace pattern, you will need to make changes manually following the instructions which will be provided in the package.
Another mandatory operation you will need to do is move certain inline scripts before their dependencies. The example above should be in this shape:
<script type="text/javascript">
window.inlineType = 'forum';
window.inlineId = 7;
</script>
<script type="text/javascript" src="jscripts/inline_moderation.js"></script>LAB.js works too well and chains all scripts in a waiting queue. Inline scripts with variables declarations can be put after external scripts and still work fine, LAB.js + pjax breaks this behavior and needs variables to be declared before. Again, proper instructions will be provided to adapt all the default JSes and custom ones.
