helenanders26

---
title: 
published: false
description: 
series:
cover_image: 
tags: 

---

jolyndenning

This Gist works for CRA 3. For CRA 4, you can try community maintained craco plugin for converting to a single-spa application at https://github.com/hasanayan/craco-plugin-single-spa-application (thanks @hasanayan):

1. Install react-app-rewired, as explained in https://github.com/timarney/react-app-rewired.
2. Create a file in src called single-spa-entry.js (or tsx for typescript)
3. Modify config-overrides.js, as shown in the config-overrides.js file provided in this gist.
4. (Optional) remove src/main.js, since single-spa-entry is the new entry
5. (Optional) remove public/index.html, since single-spa applications share a single html file, instead of one html file per project.

stolinski

const FakeComponent = () => {
  return (
      <AnimatedRoutes exitBeforeEnter initial={false}>
        <RouteTransition exact path="/some-route">
          <NewUsers />
        </RouteTransition>
        <RouteTransition exact path="/yo" >
          <Users />
        </RouteTransition>
      </AnimatedRoutes>

kripod

import React from 'react';

// Source: https://github.com/emotion-js/emotion/blob/master/packages/styled-base/types/helper.d.ts
type PropsOf<
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  E extends keyof JSX.IntrinsicElements | React.JSXElementConstructor<any>
> = JSX.LibraryManagedAttributes<E, React.ComponentPropsWithRef<E>>;

export interface BoxOwnProps<E extends React.ElementType = React.ElementType> {
  as?: E;

bradtraversy

DevCamper Backend API Specifications

Create the backend for a bootcamp directory website. The frontend/UI will be created by another team (future course). The html/css template has been created and can be used as a reference for functionality. All of the functionality below needs to be fully implmented in this project.

Bootcamps

• List all bootcamps in the database
  • Pagination
  • Select specific fields in result
  • Limit number of results

• Filter by fields

sebmarkbage

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

vcastroi

// create a bookmark and use this code as the URL, you can now toggle the css on/off
// thanks+credit: https://dev.to/gajus/my-favorite-css-hack-32g3
javascript: (function() {
	var elements = document.body.getElementsByTagName('*');
	var items = [];
	for (var i = 0; i < elements.length; i++) {
		if (elements[i].innerHTML.indexOf('* { background:#000!important;color:#0f0!important;outline:solid #f00 1px!important; background-color: rgba(255,0,0,.2) !important; }') != -1) {
			items.push(elements[i]);
		}
	}

sandren

Tailwind CSS best practices

Utility classes

1. When writing a string of multiple utility classes, always do so in an order with meaning. The "Concentric CSS" approach works well with utility classes (i.e,. 1. positioning/visibility 2. box model 3. borders 4. backgrounds 5. typography 6. other visual adjustments). Once you establish a familiar pattern of ordering, parsing through long strings of utility classes will become much, much faster so a little more effort up front goes a long way!

2. Always use fewer utility classes when possible. For example, use mx-2 instead of ml-2 mr-2 and don't be afraid to use the simpler p-4 lg:pt-8 instead of the longer, more complicated pt-4 lg:pt-8 pr-4 pb-4 pl-4.

3. Prefix all utility classes that will only apply at a certain breakpoint with that breakpoint's prefix. For example, use block lg:flex lg:flex-col lg:justify-center instead of block lg:flex flex-col justify-center to make it very clear that the flexbox utilities are only applicable at the

gillkyle

/* removes content from page layout but keeps information available to accessibility APIs */
.visually-hidden {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;

markpenaranda

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common'
import { getAction } from '@nestjsx/crud'

@Injectable()
export class RestfulCrudRoleGuard implements CanActivate {
  
    constructor(
    //   private readonly reflector: Reflector,
      public restfulCrudOptions: {
          readAllRoles: string [],