lokhmakov

import { builders as b }    from 'ast-types'


import generateRequire      from './require'
import generateListAdd      from './listAdd'


export default ({
  name,
  fields = [],

lokhmakov

const fs = require('fs').promises
const keystone = require('keystone')
const recast = require('recast')


const Types = keystone.Field.Types
const CoreEntity = new keystone.List('CoreEntity')

const generateModel = require('../lib/core/entity/api/generate/model').default

lokhmakov

import Grid                 from '@material-ui/core/Grid'
import Button               from '@material-ui/core/Button'
import { MapMarker }        from 'mdi-material-ui'
import Map                  from 'pigeon-maps'
import React, { Component } from 'react'
import ReactDOM             from 'react-dom'
import compose              from 'recompose/compose'
import lifecycle            from 'recompose/lifecycle'
import withHandlers         from 'recompose/withHandlers'
import withStateHandlers    from 'recompose/withStateHandlers'

lokhmakov

body {
  background: blue;
}

lokhmakov

const runQuery = createEffect({
  handler(props) {
    console.log(props)
  },
})

const createOnceEvent = to => {
  const from = createEvent()
  const unsubscribe = forward({from, to})
  from.watch(unsubscribe)

lokhmakov

import {
  createEvent,
  createStore,
  createEffect,
  combine,
  forward,
  Effect,
  Store,
  Event,
  step

lokhmakov

Animation Perf Test

A Pen by Pavel Lokhmakov on CodePen.

License.

lokhmakov

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

lokhmakov

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

What This Is

Technical and architectural audit of a system. This is an evolving documentation vault, not a codebase.

Language