[nodebb-plugin-magicblock] Macros, Color, Embeding

[frissdiegurke]

Great

Now that it gets in shape here are a few more recommendations/notes:

1. I guess the lib/defaults.js is never used and duplicates lib/magicblock/defaults.js, just a side note xD
2. There are a few tools at npm you could use rather than creating your own utilities I prefer lodash (link), it's written for performance and consistency of usage. Your deepCopy/buildOptions would get replaced by _.merge for example. It's really not a deal to have dependencies for such matters. Plus knowing a utilities features helps a lot keeping code to necessary stuff.
3. I see some space for improvement here; Checking opts.attrStrAllowColor first would improve the code and performance.
4. A .npmignore file does not extend of a .gitignore, you have to either fill it properly or remove it entirely (in this case npm will use the .gitignore). You have some a bit of trash within your npm release

Glad I could help!

[qgp9]

Thanks always~

@frissdiegurke said:

1. I guess the lib/defaults.js is never used and duplicates lib/magicblock/defaults.js, just a side note xD

Actually I use magicblock as a sepereated module, and lib/defaults.js is a plugin side defaults which can be different from magicblock defaults, (they are yet same but.. ). Now, buildOptions is called twice in library.js and lib/magicblock/index.js with different(but same) default.js.

2. There are a few tools at npm you could use rather than creating your own utilities I prefer lodash (link), it's written for performance and consistency of usage. Your deepCopy/buildOptions would get replaced by _.merge for example. It's really not a deal to have dependencies for such matters. Plus knowing a utilities features helps a lot keeping code to necessary stuff.

Yes, after I learned lodash from your emoji plugin, I thought exactly same thing. Thanks twice :).

3. I see some space for improvement here; Checking opts.attrStrAllowColor first would improve the code and performance.

Eagle eye!!

4. A .npmignore file does not extend of a .gitignore, you have to either fill it properly or remove it entirely (in this case npm will use the .gitignore). You have some a bit of trash within your npm release

This is really something new I have never known.
I will quickly improve 3,4 first.

[qgp9]

I got a question if this plugin works under v0.9.4.
But I tested/developed this my first plugin with only with v1.0.0, and have no idea about version compatibility.

What I can imagine to are

1. Study what changed between v0.9.4 and v1.0.0
2. Install v0.9.4 and test.
3. Ask volunteers who (will) test the plugin with one's v0.9.4

Could anybody give better or recommendable ideas?

[julian]

@qgp9 wow, great work! If you want to know what changed between versions, check for a "breaking changes" topic by @baris - that's your best bet.

For v1, likely you'll need to add an "acpScripts" section to your plugin.json, if you have client side js defined in ACP

[qgp9]

@julian HI, I needed you 30 minitues ago!!
I just found out this acpScripts after an hours testing and debuging.
I have(had) to read that post also.
Here is a link for others ( to save server resource from searching)

Actually, I have an question related with acpScript.
So if I want to support v0.9.4 then what is best way?

1. put a admin.js( commonly called ) to both of acpScript and scripts
2. put it to only scripts and remove from acpScript
3. embed into an admin tpl of a plugin.

I guess most effective way to support both versions is 3.
Could you let me know the best way?

[julian]

@qgp9 You can embed the script into the template -- depends how comfortable you are with mixing your templates and client-side code, in terms of organisation

In order to support both, you'd have to maintain two branches in git. One for each level of support. You'd need to ensure the nbbpm.compatibility values are set to the appropriate values in each branch's package.json, and npm publish them both (though npm will show the readme of the latest published version).

nbbpm should be smart enough to figure out that different versions have different compatibilities and adjust its records accordingly. If not, let me know,.

[qgp9]

Hi , All

I'm testing the plugin with v0.9.4 on Cloud9.
If you are interested on this, you can post/test freely without login.
https://nodebb-0-9-4-magicblock-qgp9.c9users.io/topic/2

It seems that [email protected] works well with [email protected]

[frissdiegurke]

@julian said:

@qgp9 You can embed the script into the template -- depends how comfortable you are with mixing your templates and client-side code, in terms of organisation

Or make the script statically available (no way to limit for admins thought) and link it within the template.

[qgp9]

@julian Thank you. I'll check them.

[qgp9]

NEWS

nodebb-plugin-magicblock has been updated to v0.1.8

A key feature of v0.1.7 is a hackIframely which can enable iFramely only in blocks {{..}} with an offical nodebb-plugin-iframely.

Check details at a plugin page.

Demo page

[psychobunny]

Nice job!