update users
set crypted_password = '$2a$12$uCkkXmhW5ThVK8mpBvnXOOJRLd64LJeHTeCkSuB3lfaR2N0AYBaSi',
salt=null,
hash_method='BCRYPT'
where login = 'admin'
<?php | |
/** | |
* Set redis configuration. | |
*/ | |
/** @see: https://docs.platform.sh/frameworks/drupal8/redis.html */ | |
if (extension_loaded('redis')) { | |
// Set Redis as the default backend for any cache bin not otherwise specified. | |
// $settings['cache']['default'] = 'cache.backend.redis'; |
FROM composer:2 as composer | |
FROM php:7-alpine | |
ENV NODE_VERSION 16.2.0 | |
ENV MACHINE_TOKEN test | |
COPY --from=composer /usr/bin/composer /usr/local/bin/ | |
RUN apk add --no-cache \ | |
libstdc++ \ | |
&& apk add --no-cache --virtual .build-deps \ | |
curl \ | |
&& ARCH= && alpineArch="$(apk --print-arch)" \ |
/** | |
* Sets up a DOM MutationObserver that watches for elements using undefined CSS | |
* class names. Performance should be pretty good, but it's probably best to | |
* avoid using this in production. | |
* | |
* Usage: | |
* | |
* import cssCheck from './checkForUndefinedCSSClasses.js' | |
* | |
* // Call before DOM renders (e.g. in <HEAD> or prior to React.render()) |
https://twitter.com/snookca/status/1073299331262889984?s=21
“In what way is JS any more maintainable than CSS? How does writing CSS in JS make it any more maintainable?”
Happy to chat about this. There’s an obvious disclaimer that there’s a cost to css-in-js solutions, but that cost is paid specifically for the benefits it brings; as such it’s useful for some usecases, and not meant as a replacement for all workflows.
(These conversations always get heated on twitter, so please believe that I’m here to converse, not to convince. In return, I promise to listen to you too and change my opinions; I’ve had mad respect for you for years and would consider your feedback a gift. Also, some of the stuff I’m writing might seem obvious to you; I’m not trying to tell you if all people of some of the details, but it might be useful to someone else who bumps into this who doesn’t have context)
So the big deal about css-in-js (cij) is selectors.
Building reusable UI components is a non trivial task, as we need to anticipate a number of things when planing for reuseability. On the one end of the spectrum we want to enable customization and on the other side we want to avoid developers doing the wrong thing, like breaking the component or displaying invalid states.
To get a better understanding of what we need to think about and consider upfront, we will build a non-trivial UI component, that displays tags. Our Tags
component will take care of managing and displaying tags.
The following examples are all built with Tachyons and React, but these ideas apply to any UI component and any general styling approach.
This is the base of all projects and it will include the foundation for all potential react-based projects in Reason.
This base package should include a ReasonReact api to promote collaboration and familiarity with people using a ReasonReact, and for the modern world of React this should also include a Hooks api that currently revery uses.
All blocks in Jsx are of type React.reactElement
. This reactElement should represent:
- Location - The location of the application. Usually just a URL, but the location can contain multiple pieces of information that can be used by an app
- pathname - The "file/directory" portion of the URL, like
invoices/123
- search - The stuff after
?
in a URL like/assignments?showGrades=1
. - query - A parsed version of search, usually an object but not a standard browser feature.
- hash - The
#
portion of the URL. This is not available to servers inrequest.url
so its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things. - state - Object associated with a location. Think of it like a hidden URL query. It's state you want to keep with a specific location, but you don't want it to be visible in the URL.
- pathname - The "file/directory" portion of the URL, like