A blog and website by Peter Bengtsson
06 February 2019 0 comments Javascript, ReactJS
React 16.8.0 with Hooks was released today. A big deal. Executive summary; components as functions is all the rage now.
What used to be this:
class MyComponent extends React.Component {
...
componentDidMount() {
...
}
componentDidUpdate() {
...
}
render() { STUFF }
}
...is now this:
function MyComponent() {
...
React.useEffect(() => {
...
})
return STUFF
}
Inside the useEffect "side-effect callback" you can actually update state. But if you do, and this is no different that old React.Component.componentDidUpdate, it will re-run the side-effect callback. Here's a simple way to cause an infinite recursion:
// DON'T DO THIS
function MyComponent() {
const [counter, setCounter] = React.useState(0);
React.useEffect(() => {
setCounter(counter + 1);
})
return <p>Forever!</p>
}
The trick is to pass a second argument to React.useEffect that is a list of states to exclusively run on.
Here's how to fix the example above:
function MyComponent() {
const [counter, setCounter] = React.useState(0);
const [times, setTimes] = React.useState(0);
React.useEffect(
() => {
if (times % 3 === 0) {
setCounter(counter + 1);
}
},
[times] // <--- THIS RIGHT HERE IS THE KEY!
);
return (
<div>
<p>
Divisible by 3: {counter}
<br />
Times: {times}
</p>
<button type="button" onClick={e => setTimes(times + 1)}>
+1
</button>
</div>
);
}
You can see it in this demo.
Note, this isn't just about avoiding infinite recursion. It can also be used to fit your business logic and/or an optimization to avoid executing the effect too often.
06 February 2019 0 comments Javascript, ReactJS, Web development
tl;dr; You can use error instanceof window.Response
to distinguish between fetch exceptions and fetch responses.
When you do something like...
const response = await fetch(URL);
...two bad things can happen.
- The XHR request fails entirely. I.e. there's not even a response with a HTTP status code.
- The response "worked" but the HTTP status code was not to your liking.
Either way, your React app needs to deal with this. Ideally in a not-too-clunky way. So here is one take on this challenge/opportunity which I hope can inspire you to extend it the way you need it to go.
The trick is to "clump" exceptions with responses. Then you can do this:
function ShowServerError({ error }) {
if (!error) {
return null;
}
return (
<div className="alert">
<h3>Server Error</h3>
{error instanceof window.Response ? (
<p>
<b>{error.status}</b> on <b>{error.url}</b>
<br />
<small>{error.statusText}</small>
</p>
) : (
<p>
<code>{error.toString()}</code>
</p>
)}
</div>
);
}
The greatest trick the devil ever pulled was to use if (error instanceof window.Reponse) {. Then you know that error thing is the outcome of THIS = await fetch(URL) (or fetch(URL).then(THIS) if you prefer). Another good trick the devil pulled was to be aware that exceptions, when asked to render in React does not naturally call its .toString() so you have to do that yourself with {error.toString()}.
This codesandbox demonstrates it quite well. (Although, at the time of writing, codesandbox will spew warnings related to testing React components in the console log. Ignore that.)
If you can't open that codesandbox, here's the gist of it:
React.useEffect(() => {
url &&
(async () => {
let response;
try {
response = await fetch(url);
} catch (ex) {
return setServerError(ex);
}
if (!response.ok) {
return setServerError(response);
}
// do something here with `await response.json()`
})(url);
}, [url]);
By the way, another important trick is to be subtle with how you put the try { and } catch(ex) {.
// DON'T DO THIS
try {
const response = await fetch(url);
if (!response.ok) {
setServerError(response);
}
// do something here with `await response.json()`
} catch (ex) {
setServerError(ex);
}
Instead...
// DO THIS
let response;
try {
response = await fetch(url);
} catch (ex) {
return setServerError(ex);
}
if (!response.ok) {
return setServerError(response);
}
// do something here with `await response.json()`
If you don't do that you risk catching other exceptions that aren't exclusively the fetch() call. Also, notice the use of return inside the catch block which will exit the function early leaving you the rest of the code (de-dented 1 level) to deal with the happy-path response object.
Be aware that the test if (!response.ok) is simplistic. It's just a shorthand for checking if the "status in the range 200 to 299, inclusive". Realistically getting a response.status === 400 isn't an "error" really. It might just be a validation error hint from a server, and likely the await response.json() will work and contain useful information. No need to throw up a toast or a flash message that the communication with the server failed.
Conclusion
The details matter. You might want to deal with exceptions entirely differently from successful responses with bad HTTP status codes. It's nevertheless important to appreciate two things:
Handle complete fetch() failures and feed your UI or your retry mechanisms.
You can, in one component distinguish between a "successful" fetch() call and thrown JavaScript exceptions.
01 February 2019 2 comments Python
tl;dr; Use f"{number:,}" to thousands format an integer to a string.
I keep forgetting and having to look this up every time. Hopefully by blogging about it, this time it'll stick in my memory. And hopefully in yours too :)
Suppose you have a number, like 1234567890 and you want to display it, here's how you do it:
>>> number = 1234567890
>>> f"{number:,}"
'1,234,567,890'
In the past, before Python 3.6, I've been using:
>>> number = 1234567890
>>> format(number, ",")
'1,234,567,890'
All of this and more detail can be found in PEP 378 -- Format Specifier for Thousands Separator. For example, you can do this beast too:
>>> number = 1234567890
>>> f"{number:020,.2f}"
'0,001,234,567,890.00'
which demonstrates (1) how to do zero-padding (of length 20), (2) the thousands comma, (3) round to 2 significant figures. All useful weapons to be able to draw from the top of your head.
UPDATE
Also, incredibly useful is the equivalent of somestring.ljust(10):
>>> mystr = "peter"
>>> f"{mystr:10}"
'peter '
>>> f"{mystr:>10}"
' peter'
31 January 2019 0 comments Python
Prior to version 0.14.5 hashin would write write down the hashes of PyPI packages in the order they appear in PyPI's JSON response. That means there's a slight chance that two distinct clients/computers/humans might actually get different output when then run hashin Django==2.1.5.
The pull request has a pretty hefty explanation as it demonstrates the fix.
Do note that if the existing order of hashes in a requirements file is not in the "right" order, hashin won't correct it unless any of the hashes are different.
Thanks @SomberNight for patiently pushing for this.
29 January 2019
0 comments Linux, MacOSX
Suppose you have a cleartext file that you want to encrypt with a password, here's how you do that with ccrypt on macOS. First:
Now, you have the ccrypt program. Let's test it:
▶ cat secrets.txt
Garage pin: 123456
Favorite kid: bart
Wedding ring order no: 98c4de910X
▶ ccrypt secrets.txt
Enter encryption key: ▉▉▉▉▉▉▉▉▉▉▉
Enter encryption key: (repeat) ▉▉▉▉▉▉▉▉▉▉▉
# Note that the original 'secrets.txt' is replaced
# with the '.cpt' version.
▶ ls | grep secrets
secrets.txt.cpt
▶ less secrets.txt.cpt
"secrets.txt.cpt" may be a binary file. See it anyway?
There. Now you can back up that file on Dropbox or whatever and not have to worry about anybody being able to open it without your password. To read it again:
▶ ccrypt --decrypt --cat secrets.txt.cpt
Enter decryption key: ▉▉▉▉▉▉▉▉▉▉▉
Garage pin: 123456
Favorite kid: bart
Wedding ring order no: 98c4de910X
▶ ls | grep secrets
secrets.txt.cpt
Or, to edit it you can do these steps:
▶ ccrypt --decrypt secrets.txt.cpt
Enter decryption key: ▉▉▉▉▉▉▉▉▉▉▉
▶ vi secrets.txt
▶ ccrypt secrets.txt
Enter encryption key:
Enter encryption key: (repeat)
Clunky that you have you extract the file and remember to encrypt it back again. That's where you can use emacs. Assuming you have emacs already installed and you have a ~/.emacs file. Add these lines to your ~/.emacs:
(setq auto-mode-alist
(append '(("\\.cpt$" . sensitive-mode))
auto-mode-alist))
(add-hook 'sensitive-mode (lambda () (auto-save-mode nil)))
(setq load-path (cons "/usr/local/share/emacs/site-lisp/ccrypt" load-path))
(require 'ps-ccrypt "ps-ccrypt.el")
By the way, how did I know that the load path should be /usr/local/share/emacs/site-lisp/ccrypt? I looked at the output from brew:
▶ brew info ccrypt
ccrypt: stable 1.11 (bottled)
Encrypt and decrypt files and streams
...
==> Caveats
Emacs Lisp files have been installed to:
/usr/local/share/emacs/site-lisp/ccrypt
...
Anyway, now I can use emacs to open the secrets.txt.cpt file and it will automatically handle the password stuff:
About to open
Opening with password
Opened
This is really convenient. Now you can open an encrypted file, type in your password, and it will take care of encrypting it for you when you're done (saving the file).
Be warned! I'm not an expert at either emacs or encryption so just be careful and if you get nervous take precaution and set aside more time to study this deeper.
22 January 2019 0 comments Python, Django
tl;dr; If you use the django.views.decorators.cache.cache_control decorator, consider this one instead to change the max_age depending on the request.
I had/have a Django view function that looks something like this:
@cache_control(public=True, max_age=60 * 60)
def home(request, oc=None, page=1):
...
But, that number 60 * 60 I really needed it to be different depending on the request parameters. For example, that oc=None, if that's not None I know the page's Cache-Control header can and should be different.
So I wrote this decorator:
from django.utils.cache import patch_cache_control
def variable_cache_control(**kwargs):
"""Same as django.views.decorators.cache.cache_control except this one will
allow the `max_age` parameter be a callable.
"""
def _cache_controller(viewfunc):
@functools.wraps(viewfunc)
def _cache_controlled(request, *args, **kw):
response = viewfunc(request, *args, **kw)
copied = kwargs
if kwargs.get("max_age") and callable(kwargs["max_age"]):
max_age = kwargs["max_age"](request, *args, **kw)
# Can't re-use, have to create a shallow clone.
copied = dict(kwargs, max_age=max_age)
patch_cache_control(response, **copied)
return response
return _cache_controlled
return _cache_controller
Now, I can do this instead:
def _best_max_age(req, oc=None, **kwargs):
max_age = 60 * 60
if oc:
max_age *= 10
return max_age
@variable_cache_control(public=True, max_age=_best_max_age)
def home(request, oc=None, page=1):
...
I hope it inspires.
