satya164

#!/bin/bash
# This script export all docker compose files installed via CasaOS store

mkdir -p docker-compose

appids=$(casaos-cli app-management list apps | tail -n +3 | cut -d' ' -f1)

for id in $appids
do
  casaos-cli app-management show local $id --yaml > docker-compose/${id}.yml

satya164

diff --git a/android/build.gradle b/android/build.gradle
index 525cb31..6af104d 100644
--- a/android/build.gradle
+++ b/android/build.gradle
@@ -36,7 +36,30 @@ def getExtOrIntegerDefault(name) {
   return rootProject.ext.has(name) ? rootProject.ext.get(name) : (project.properties["MyLib_" + name]).toInteger()
 }
 
+def supportsNamespace() {
+  def parsed = com.android.Version.ANDROID_GRADLE_PLUGIN_VERSION.tokenize('.')

satya164

Handle deep link + auth in React Navigation

The problem

In React Navigation 5, we use conditional rendering to show auth screens when user is not logged in. This works well, but makes it difficult to use when using it with deep links.

Consider the following flow:

• User opens the app from a deep link to a screen which is only accessible to logged in users
• React Navigation tries to handle the deep link

satya164

Shared Navigator

This is a UI and router agnostic navigator that aims to make it easier to build navigators with shared transitions between screens. All it does is keep track of animations in various screens so that the UI code can focus on animations instead.

Basic API

The basic API looks like this:

const Shared = createSharedNavigator(StackRouter);

satya164

React Navigation Static API

React Navigation has a dynamic API which makes it possible to achieve advanced and use cases. But it can result in additional boilerplate and duplication. The goal of this static API is to provide a simpler API for simple use cases.

Basic API

const MyNavigation = createNavigation({
  // Type of the navigator, takes the 'createXNavigator' function from respective package
  type: createStackNavigator,

satya164

import * as React from 'react';
import { Animated, Keyboard, KeyboardEvent, Platform } from 'react-native';

type Props = {
  offset?: number;
};

type State = {
  keyboardHeightAnim: Animated.Value;
};

satya164

{
  "extends": ["tslint:recommended", "tslint-config-prettier"],
  "rulesDirectory": ["tslint-plugin-prettier", "tslint-microsoft-contrib"],
  "rules": {
    "prettier": true,

    "deprecation": true,
    "interface-over-type-literal": false,
    "member-access": [true, "no-public"],
    "no-default-export": false,

satya164

const dashify = text => text.replace(/([a-z])([A-Z])/g, '$1-$2').toLowerCase();
const unitless = {
  animationIterationCount: true,
  borderImageOutset: true,
  borderImageSlice: true,
  borderImageWidth: true,
  boxFlex: true,
  boxFlexGroup: true,
  boxOrdinalGroup: true,
  columnCount: true,

satya164

JavaScript Style Library Wishlist

• Familiar CSS syntax: Using CSS syntax makes it easier to copy/paste code from devtools and the internet, and a huge productivity boost.
• SCSS like & shorhand: Super nice to write things like &:hover without having to write selectors again.
• Nesting media queries: Nice to nest media queries inside a style block instead of having to declare it like plain CSS.
• Support for CSS animations: CSS animations are great :)
• No coupling to HTML tag: HTML tags have semantic meaning, and coupling styles to HTML tags makes it harder to re-use the same styles, for example, sometimes some of my buttons and links have similar styles and I don't wanna repeat them.
• Easy to override styles: Overriding styles is one of the main pain points. Many libs don't do anything special and just produce different class names for the styles I declare. Due to no class name having higher specificity, the styles depend on the declaration order which can produce inconsistent

satya164

/* @flow */

import types from 'ast-types';
import { parse } from 'babylon';

const config = {
  "sourceType": "module",
  "plugins": [
    "jsx",
    "flow",