| /* Using a JavaScript proxy for a super low code REST client */ | |
| // via https://dev.to/dipsaus9/javascript-lets-create-aproxy-19hg | |
| // also see https://towardsdatascience.com/why-to-use-javascript-proxy-5cdc69d943e3 | |
| // also see https://github.com/fastify/manifetch | |
| // also see https://github.com/flash-oss/allserver | |
| const createApi = (url) => { | |
| return new Proxy({}, { | |
| get(target, key) { | |
| return async function(id = "") { | |
| const response = await fetch(`${url}/${key}/${id}`) |
Last updated: 2021-02-21, tested with socket.io v3.1.1
This is the simplest implementation you will find for a client/server WebSockets architecture using socket.io.
To see a full explanation, read my answer on SO here: https://stackoverflow.com/a/24232050/778272.
If you're looking for examples using frameworks, check these links:
| /** | |
| * Remove acentos de caracteres | |
| * @param {String} stringComAcento [string que contem os acentos] | |
| * @return {String} [string sem acentos] | |
| */ | |
| function removerAcentos( newStringComAcento ) { | |
| var string = newStringComAcento; | |
| var mapaAcentosHex = { | |
| a : /[\xE0-\xE6]/g, | |
| e : /[\xE8-\xEB]/g, |
| const socketio = require('feathers-socketio') | |
| const authOnSocketConnect = require('./authenticate-on-socket-connect') | |
| // ... Setup your Feathers app code or use the generator then replace the socketio registration with this | |
| // When you register the feathers-socketio plugin, use the utility | |
| app.configure(socketio(function (io) { | |
| // Get Socket.io headers | |
| io.on('connection', function (socket) { | |
| authOnSocketConnect({ app, socket }) |
| /** | |
| * Given you have a JSON string that represents a single object (not array). | |
| * SanitizeJsonString will attempt to correct the JSON syntax allowing | |
| * it to be parsed. | |
| */ | |
| /** | |
| * Sanitize user input before attempting to parse the JSON | |
| * |
Este método evita conflitos durante eo merge, se você tem que periódicamente fazer pull da master em sua branch. Também da a oportuniadade de realizar squash em mais de um commit ou para re-organizar seu código completamente em diferentes commits (ex: se você terminou seu trabalho em três diferente features mas os commits não foram consecutivos).
*Nota: Você não pode usar esse método se você pretende abrir um Pull Request para realizer merge da sua branch. Esse método requer commits diretamente na master.
Troque para a branch master e certifique-se de estar tudo atualizado:
| const uid = () => 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, (c) => { | |
| const r = Math.random() * 16 | 0 | |
| const v = c === 'x' ? r : r & 0x3 | 0x8 | |
| return v.toString(16) | |
| }) |
good doc! some quick answers -
It seems like act() is being recommended for wrapping all state updates in React tests, but is it necessary to use it everywhere if you can use waitForElement to turn the whole test async?
This is a very good question, and something I grappled with earlier. A couple of things that stood out for me -
waiting for an element is indeed pretty close to what a user's experience is like; ie - a user 'waits' for the form to show itself, after which they fill it in and click a button, then 'wait' for the success screen etc. Ultimately, act() makes this test stronger - it'll ensure that effects, and queued promises, have been flushed before you interact with the element. wrapping waitForElement with act() (the async version, ie), will make this invisible to the user, but with the guarantee that their UI is 'stable'.
I couldn't assume that all tests would use waitForElement. For example, using timers is common for testing transitions and such. In these scenarios too, ac
