unional / async-fp Goto Github PK

View Code? Open in Web Editor NEW

2.0 2.0 1.0 1.58 MB

Asynchronous Functional Programming Utilities

JavaScript 0.75% TypeScript 98.57% Shell 0.67%

async context dependency fp functional functional-programming promise typescript

async-fp's People

Contributors

Stargazers

Watchers

Forkers

harunaoseni

async-fp's Issues

allow gizmo.create() to be sync

// instead of
const gizmo = define({
  async create() {}
})

// allows
const gizmo = define({
  create() {}
})

The complicated thing is correctly inferring the types.

gizmo: access control

From justland/just-web#22

Besides define.require() and define.optional(),

we can have define.readonly.require() and define.readonly.optional() (or something similar),
to indicate the gizmo only need read only access to the dependency.

gizmo: define.InferDeps<typeof gizmo>

const x = define({
  static: define.require<define.InferDeps<typeof y>>(),
  async create(ctx) {
    return incubate(ctx).with(y).create()
  }
})

const x = define({
  static: define.depsOf<typeof y>(),
  async create(ctx) {
    return incubate(ctx).with(y).create()
  }
})

extend after get

Some code calls get() and pass the context to another code.
That other code call extend() to add more stuff.
This doesn't work as the get() call is cached.

gizmo.compose(context)

Instead of adding features to gizmo with .with(gizmo),

add the ability to compose multiple created gizmos together.
This is useful to compose gizmo from other teams during runtime.

export async function activate({ context }: { context: AuthGizmo }) {
  const gizmo = await incubate().compose(context).with(featureGizmo).create()
}

infers gizmo function with optional params

It doesn't work due to microsoft/TypeScript#53792

AsyncContext: improve AsyncContext type system

Similar to @just-web/app createApp().extend()

Type instantiation is excessively deep and possibly infinite.

When using .merge() twice.

gizmo: dynamic loader

const loader = (gizmos: Gizmo[], result: AnyRecord) => (identifier: string) => Promise<AnyRecord>

incubator().with(...).create(loader)

Only when there are dynamic dependencies.

UPDATE:

to work with #186:

incubator().with(...).create((gizmo, ctx) => {
  ctx.setDynamicLoader(...)
  return () => clean up
}

// only set once and remove from the chain
incubator().loader().with(...).create()

gizmo: support various instantiation strategies

const ioc = container()

ioc.register(gizmo, strategy)

There are multiple strategy options: singleton, per-branch, per-container, always-create

incubator() uses always-create for simplicity.
Could change if per-branch is needed

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

chore(deps): update dependency typescript to v5.4.3
chore(deps): update dependency @size-limit/preset-small-lib to v11
chore(deps): update dependency size-limit to v11
chore(deps): update typescript-eslint monorepo to v7 (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
Click on this checkbox to rebase all open PRs at once

Detected dependencies

github-actions

.github/workflows/pull-request.yml

.github/workflows/release.yml

npm

package.json

@changesets/cli ^2.26.0

@commitlint/cli ^19.0.0

@commitlint/config-conventional ^19.0.0

@types/jest ^29.0.0

@typescript-eslint/eslint-plugin ^6.0.0

@typescript-eslint/parser ^6.0.0

eslint ^8.22.0

eslint-config-prettier ^9.0.0

eslint-plugin-harmony ^7.1.2

husky ^9.0.0

pinst ^3.0.0

rimraf ^5.0.0

turbo ^1.4.3

typescript 5.1.6

pnpm 8.15.5

packages/async-context/package.json

iso-error ^6.0.2

type-plus ^7.0.1

@repobuddy/jest ^3.2.0

@repobuddy/typescript ^2.0.0

@size-limit/preset-small-lib ^9.0.0

@types/setimmediate ^1.0.2

assertron ^11.0.1

cross-env ^7.0.3

depcheck ^1.4.3

jest ^29.5.0

jest-esm-transformer-2 ^1.0.0

jest-watch-suspend ^1.1.2

jest-watch-toggle-config-2 ^2.1.0

jest-watch-typeahead ^2.2.2

npm-run-all2 ^6.0.0

repobuddy ^1.0.2

rimraf ^5.0.0

setimmediate ^1.0.5

size-limit ^9.0.0

ts-jest ^29.1.0

node >= 14.16

packages/async-fp/package.json

@repobuddy/jest ^3.2.0

@repobuddy/typescript ^2.0.0

@size-limit/preset-small-lib ^9.0.0

assertron ^11.0.1

cross-env ^7.0.3

depcheck ^1.4.3

jest ^29.5.0

jest-esm-transformer-2 ^1.0.0

jest-watch-suspend ^1.1.2

jest-watch-toggle-config-2 ^2.1.0

jest-watch-typeahead ^2.2.2

npm-run-all2 ^6.0.0

repobuddy ^1.0.2

rimraf ^5.0.0

size-limit ^9.0.0

ts-jest ^29.1.0

type-plus ^7.0.1

node >= 14.16

packages/gizmo/package.json

type-plus ^7.0.1

@repobuddy/jest ^3.2.0

@repobuddy/typescript ^2.0.0

@size-limit/preset-small-lib ^9.0.0

assertron ^11.0.1

cross-env ^7.0.3

depcheck ^1.4.3

jest ^29.5.0

jest-esm-transformer-2 ^1.0.0

jest-watch-suspend ^1.1.2

jest-watch-toggle-config-2 ^2.1.0

jest-watch-typeahead ^2.2.2

npm-run-all2 ^6.0.0

repobuddy ^1.0.2

rimraf ^5.0.0

size-limit ^9.0.0

ts-jest ^29.1.0

node >= 14.16

Check this box to trigger a request for Renovate to run again on this repository

incubator.create(startFn)

const incubator = incubate().with()...

const gizmo = await incubator.create(async (gizmo) => {
    /** do startup work before the instance is returned **/
})

Async Traits

from justland/just-web#154

What is the async nature? During build (.extend())? or during .start()?
createApp().start() allows plugin to do some async work to get ready.

While the .extend() call adding interface synchronously.
Is that needed?
Can we just extend and wait for start to happen before getting the resulting extended object?

That lost the type checking during .extend(). Should that be missed? Or there is a way to internally track the type using something like PromiseValue<T> to get the expected Trait and keep going?

An in-range update of semantic-release is breaking the build 🚨

The devDependency semantic-release was updated from `15.13.15` to `15.13.16`.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

semantic-release is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

✅ ci/circleci: node-latest: Your tests passed on CircleCI! (Details).
✅ ci/circleci: node8: Your tests passed on CircleCI! (Details).
✅ ci/circleci: node10: Your tests passed on CircleCI! (Details).
✅ codecov/project: No report found to compare against (Details).
✅ codecov/patch: Coverage not affected. (Details).
✅ coverage/coveralls: First build on greenkeeper/semantic-release-15.13.16 at 100.0% (Details).
❌ Travis CI - Branch: The build failed.
✅ all: * node-latest - Success

node10 - Success
node8 - Success

Release Notes for v15.13.16

15.13.16 (2019-06-07)

Bug Fixes

package: update env-ci to version 4.0.0 (8051294)

Commits

The new version differs by 3 commits.

4ed6213 style: fix prettier style
8051294 fix(package): update env-ci to version 4.0.0
95a0456 chore(package): update ava to version 2.0.0

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

gizmo: support cleanup

justland/just-web#21

const gizmo = define({
  async create() {
    return [{}, () => () => 'clean up']
  }
})

How to trigger? This will be breaking change:

const [app, cleanup] = await incubate().with(...).create()

cleanup()

One solution is to use symbol:

const app = await incubate().with(...).create()

await cleanup(app)

async function cleanup(app) {
  app[destructorSymbol]()
}

or use the same pattern:

const app = await incubate().with(...).create(() => () => clean up)

This design conflict with #161.
Need to find to way to make both of them work.

incubate(gizmo) does not check type correctly

from just-web:

const i = incubate(logGizmo()) // i !== MissingDependency<'name' | 'id'>

gizmo: extend()

Using incubate(ctx).with(...).create() to extends gizmo is not optimal:

const subGizmo = define({
  static: define.require<A & B & C>(),
  async create(ctx) {
    return incubate(ctx).with(d).with(e).create()
  }
})

This overrides whatever sub gizmo of A/B/C used by the app. e.g.:

const gizmoA = define({
  async create() {
    return {
      a: { x() {} }
    }
  }
}

const subA = define({
  async create() {
    const { a } = await incubate().with(gizmoA).create()
    return {
      a: { 
        ...a,
        y() {}
      }
    }
  }
})

const gizmo = incubate().with(subA).with(gizmoB).with(gizmoC).with(subGizmo).create()

// gizmo got the base `gizmoA` prop because the subGizmo overrides the `subA`
gizmo.a.x() // exist
gizmo.a.y() // does not exist

The correct way is:

const subGizmo = define({
  static: define.require<A & B & C>(),
  async create(ctx) {
    const { d, e } = await incubate(ctx).with(d).with(e).create()
    return { d, e }
  }
})

which is tedious.

Add an extends() function or similar to:

const subGizmo = define({
  static: define.require<A & B & C>(),
  async create(ctx) {
    return extends(ctx).with(d).with(e).create() // returns only { d, e }
  }
})

or maybe:

const subGizmo = define({
  static: define.require<A & B & C>(),
  async create(ctx) {
    return incubate(ctx).with(d).with(e).createSubGizmo() // returns only { d, e }
  }
})