Minor issue, having your event handlers (lambda functions) declared *in* your component context, then passing to "pure" components will trigger a re-evaluation cycle as the functions themselves don't match the prior instance.
I usually just stow the original initialization promise, and return that on future requests...
let _instance = null;
export default async function getResource(opts) {
if (_instance) return instance;
_instance = intializeInstance(otps).then(i => (
_instance = i
));
return _instance;
}
This will stow the promise, returning it initially, then when the concrete instance is there, will start returning that.
FYI: Will usually remove content/articles tethered to a paid service (see about link at the bottom of the site)
Leaving this as it does provide some value beyond the link to the commercial Netlify site. I also know a lot of people do get a lot of utility from the free level.
Some suggestions for followup for those that want to brew their own solution would be to look at github/gitlab automation options, and take a look at Dokku, which is really great for targeted deployments at small scale. A $10/month account from DigitalOcean or Linode, or any VPS will pretty much do the job for mostly static or small scale sites/apps. Dokku also has a pretty transparent plugin for use with Let's Encrypt (make sure to enable the cron event, and set your email environment variable)
I'm just really not a fan of Tailwind and growing less a fan of Bootstrap. Tailwind in particular uses classes like "text-white" etc, instead of purpose driven classes.
Even then, I'm more of a fan of JSS at this point as it allows for component driven styles that share a common theme. This means that you can define your color pallets by use/purpose over the name of the color. It also allows for the exclusion of styles that are no longer used, because a component was dropped or changed.
I always find stale CSS rules when auditing sites... why, because everything, the kitchen sink, the kitchen and the entire condo and the neighboring park tends to get added over time. I know the purpose of CSS was to separate styling rules from the content for flexibility, and always loved the CSS Zen site for great ideas. But the fact is that the CSS and the content are tethered together, and even more so in applications.
The way these frameworks work is that there is usually a lot of cruft that builds over time.
From the source, seems to assume that each read chunk is suitable for markdown transformation separately, and that the final chunk in a stream will never happen.
You're creating a `new Function(...)`, this and `eval` are blocked by static analysis tooling, ad network linting applications, and other code linting tools such as eslint[1].
const compile = (template) => {
return new Function("data", "return " + compileToString(template))
}
[1] https://eslint.org/docs/rules/no-new-func
The use of eval and dynamic function creation are blocked by quite a few linters by default. This will be doubly so in most ad networks, if you happen to be targeting that context.
It's an interesting ui-library, it does remind me a bit of Bootstrap, though fewer components and less polished. From the documentation site, the colors/contrast are stark to say the least. Not my taste, but some may like it. Should also consider a few more fallback fonts, especially if you intend to support emoji character rendering in your site/application.