It's pretty much the exception to the rule. The main application I'm working on now isn't using SSR, so it doesn't hurt me to have a global __BASE__ state, this is where I inject configuration variables/options as well as a lot of the localization/strings. There's also localStorage and sessionStorage. Not *EVERYTHING* belongs in redux and there's no shame in putting a couple details like this outside that scope.
I tend to do my UI/node dev locally, but have been working on stack deployments to docker, as well as running the tiers I'm not actively in within containers locally. It's been really nice.
Gotcha worth note, do *NOT* use volumes for live database files in windows or mac... docker desktop runs in a vm and uses a file cloning service between the container and the desktop for volume mounts, unlike actual Linux. database backup/restore path or other volumes are generally okay, but scenarios with lots of read-write operations are bad in mac/windows.
Even beyond the link shortener, there are a few domains apparently in a spam filter for the submission, so the authors now submit a blurb with the url in the blurb. I don't know what the honestly expect, there's rel=nofollow on all the links here, it's not like they gain SSO from this site.
I agree... I've thought about trying to get the app running locally, etc.. so I can try and maybe create a node/js version of the site, running against the same database. I don't remember enough ruby to be productive at all in the codebase either.
I write node scripts that run from package.json and/or interface with utilities/binaries from npm packages mostly. Even for projects that aren't node, as it's installed everywhere.
Here's an example from an active mono-repo.
"husky": {
"hooks": {
"pre-commit": "node -r esm !main/scripts/run-child-npm-task precommit"
}
},
"scripts": {
"reset:db": "node -r esm !main/scripts/reset-db",
"build": "node -r esm !main/scripts/run-child-npm-task build",
"test": "node -r esm !main/scripts/run-child-npm-task test",
"first-init": "node -r esm !main/scripts/first-init"
}
A typical script for me has the following shell…
import path from "path";
import shell from "shelljs";
export async function main(skip) {
if (skip) return;
... work goes here ...
}
main(!!module.parent).catch(err => {
console.error(err);
process.exit((err && err.code) || 666);
});
Generally, path and shelljs are nearly always used, so I start with the above and add more as needed. the mz package has also been useful, but mostly replaced with internal options.
As to comments on deleting accounts, it's really easy to create an account... and even then, a lot of it may be done manually so that even if you delete an account a new one could be created, even with a captcha etc.
A lot of the spammy articles are from accounts that only have one article posted. Requiring X karma (at least an upvoted comment or something) might help the bulk of it.
It depends on what the focus is. I might recommend a jQuery base for a web based application that didn't serve to mostly display content today, outside of that VueJS is about as easy to graft on, similar for preact/inferno as other JSX/React look alikes at a relatively low overhead.
My preference for applications is for React first. Vue just doesn't feel like it would scale to full-size Applications. Both vue and angular seem to have holes in their server-rendering options and angular in particular seems far more complicated than putting the lego pieces together with react + mobx/redux and fetch/axios.
There are a few jquery alternatives if you want to inherit most of the utility bits without the bulk.
I write node scripts that run from package.json and/or interface with utilities/binaries from npm packages mostly. Even for projects that aren't node, as it's installed everywhere. Here's an example from an active mono-repo. "husky": { "hooks": { "pre-commit": "node -r esm !main/scripts/run-child-npm-task precommit" } }, "scripts": { "reset:db": "node -r esm !main/scripts/reset-db", "build": "node -r esm !main/scripts/run-child-npm-task build", "test": "node -r esm !main/scripts/run-child-npm-task test", "first-init": "node -r esm !main/scripts/first-init" } A typical script for me has the following shell… import path from "path"; import shell from "shelljs"; export async function main(skip) { if (skip) return; ... work goes here ... } main(!!module.parent).catch(err => { console.error(err); process.exit((err && err.code) || 666); }); Generally, path and shelljs are nearly always used, so I start with the above and add more as needed. the mz package has also been useful, but mostly replaced with internal options.