This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.
On March 29th, 2024, a backdoor was discovered in xz-utils, a suite of software that
[11:45 PM] someuser : how can I pull data from mysql database using react js?
[11:46 PM] BTM : @someuser short answer - "you can't"
[11:46 PM] connor : have react hit a proxied api that makes request using mysql
[11:46 PM] connor : using fetch or axios
[11:46 PM] someuser : the package has apollo in it
[11:46 PM] BTM : You need an API that will expose the data from sql as REST, graphql etc.
[11:46 PM] someuser : whats the apollo for?
[11:46 PM] someuser : im confused between graphql, apollo and redux.
[11:46 PM] acemarke : okay, let me explain
[11:47 PM] acemarke : first: no matter what UI framework you're using, here's the basic data flow
Last Updated: 8/30/18
I wanted to run an OpenVPN server on the USG. Since it has a Radius server built in, I figured this would be a much better way to handle OpenVPN authentication. Make sure you have the Radius server enabled on your USG under Settings > Services > Radius > Server in the controller. Add OpenVpn users under Settings > Services > Radius > Server.
Thanks to the following resources in helping to configure this:
This is a fork of original gist https://gist.github.com/nrollr/3f57fc15ded7dddddcc4e82fe137b58e, with slight changes on pointing to 5.7 version branch, instead of 8 (latest default of MySQL in Hombrew).
This procedure explains how to install MySQL using Homebrew on macOS (Sierra 10.12 and up)
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Note:
When this guide is more complete, the plan is to move it into Prepack documentation.
For now I put it out as a gist to gather initial feedback.
If you're building JavaScript apps, you might already be familiar with some tools that compile JavaScript code to equivalent JavaScript code:
All libraries have subtle rules that you have to follow for them to work well. Often these are implied and undocumented rules that you have to learn as you go. This is an attempt to document the rules of React renders. Ideally a type system could enforce it.
A number of methods in React are assumed to be "pure".
On classes that's the constructor, getDerivedStateFromProps, shouldComponentUpdate and render.
| # Assumes 3 sequential commits: | |
| # | |
| # 1. commit tagged "prettier-before" that added `prettier` depedency and `prettier` script your package.json | |
| # 2. commit that actually ran `prettier` on your entire codebase for the first time | |
| # 3. commit tagged "prettier-after" that fixes any minor issues caused by prettier (e.x. moving eslint-ignore or $FlowFixMe comments around), or just the next commit if there were none | |
| # | |
| # I recommend running these as individual commands, not as a script, in case of merge conflicts | |
| # | |
| # Checkout the non-pretty branch you want to merge | |
| # (or optionally make a new branch with `git checkout -b $YOUR_BRANCH-prettier $YOUR_BRANCH`) |
| // @ts-check | |
| // Requires module: slug, gatsby-source-filesystem | |
| const path = require('path') | |
| const slugify = require('slug') | |
| const { createFilePath } = require('gatsby-source-filesystem') | |
| // Regex to parse date and title from the filename | |
| const BLOG_POST_SLUG_REGEX = /^\/blog\/([\d]{4})-([\d]{2})-([\d]{2})-(.+)\/$/ |
| module.exports = { | |
| root: true, // make to not take in any user specified rules in parent folders | |
| parser: 'babel-eslint', | |
| extends: ['airbnb', 'prettier', 'prettier/flowtype', 'prettier/react'], | |
| env: { | |
| browser: true, | |
| node: true, | |
| jest: true, | |
| }, | |
| plugins: ['flowtype'], |
