elegant, type-safe state management
asyncActionMatcher(phase, operation)
would be better if written as
asyncActionMatcher(operation, phase)
It was written the first way because, in the implementation of asyncLifecycle, asyncActionMatcher() is called with no operation (because the operation may be anonymous, and the resulting matcher is verifying uuid as well, which is narrower than matching on operation).
however, end users will very much more frequently be calling asyncActionMatcher() with an operation, but no specific phase - meaning, "match any action dispatched for this operation".
we should be catering to the end user's common use case, not the one internal use case.
The render prop pattern is great for most use cases, but sometimes it's necessary to have access to state, dispatch in the component lifecycle. Since render props only inject the references into the render() function, you'd currently have to wrap your lifecycle component to get access to those values:
const Wrapper = () =>
<Subscriber>{
(state, dispatch) =>
<Wrapped state={state} dispatch={dispatch} />
}</Subscriber>
class Wrapped extends React.Component {
// I can now use state and dispatch in my lifecycle here
}
It would be more usable for these use cases if the components were also offered as HOC, allowing the user to simply decorate their existing lifecycle component rather than wrapping it.
npm version <step> normally creates a commit and a git tag for the version increment. However, since this is a monorepo, npm skips that step (presumably because it doesn't want to assume your release strategy).
release.sh could easily step in here by capturing the changes after npm version is run and creating a commit for it.
we want the TypeDoc API docs to be readable from the web, and linkable in the README/example snippets.
I actually don't know how gh-pages works, but it should be fairly trivial to run typedoc on the entire project. (currently it is run on a per-module basis). TypeDoc may be ugly, but it converts JSDoc into web pages and that's what matters. (maybe someday we can write a TypeDoc theme that actually looks good).
A pattern should also be established for regenerating/updating the docs - perhaps as a precommit hook or similar. It is not completely out of the question that the generated docs be tracked in version control (after all, I think they need to exist in a branch somewhere to get them hosted on github pages anyway).
Once this is done, there is really no reason to continue generating them on a per-module basis and publishing them with the node module artifact - it's just extra bloat. The README links should work from anywhere.
so:
build.shbox(key, reducer) takes a reducer and maps it to the given key.
Another convenience reducer, id(reducer, getId: (action) => id) could take a reducer and, using the given getId, map actions matched by that reducer into an id derived from the action.
This is very similar to "lens", but there's really only one use case where lens makes sense, so an actual lens implementation would be overkill.
<Async> could easily be extended to handle well-known request types. For example:
<Fetch url={} options={} />
or from RxJS
<Ajax ... />
GraphQL would be very useful, accepting a GQL query and endpoint location.
These specific request-type components could possibly also be prewired with io-ts or something.
It's very realistic that users of <Controllable> will need to access dispatch outside of render() (i.e., during lifecycle methods). React uses a ref prop to allow access to a node in lifecycle methods - <Controllable> could accept a bindDispatch prop that would do the same thing.
Each module should have a changelog file that enumerates the commits in a given release. When the release script is used, it should append the commits to a CHANGELOG.md file in the current directory.
Currently, the release script bumps the package version using npm version, but does not automatically create a version bump commit. The script should be modified to create such a commit (with the message: package-name@new-version), and the commit should also contain the changelog update.
When determining the commits to add to the changelog, the script should include all commits up to, but excluding, the last "release commit".
This change should be introduced as part of the 1.0.0 release for all 3 modules; the initial changelog should contain all commits that have been added thus far.
The project should utilize CI, probably using something like Travis.
prettierdocslerna-changelog to update the changelogIf all of the above are completed, the existing scripts directory would become completely unnecessary.
There are several known conditions that will cause problems for the user. For example, calling asyncLifecycle() with an anonymous function means that stately cannot infer a human-readable "infix" for the action type string. These conditions should be reviewed, and a linter rule should complain to the user whenever possible. (the above should certainly be possible)
The current stately usage guides in the READMEs are essentially big text walls with some examples. These need to be revised, updated, reorganized, or whatever is necessary to keep them succinct but clear. At the moment there does not appear to be anyone who has read the guides and actually come to an understanding of stately as a result...
There are no JSDoc API docs for these yet.
when running the stately-react tests, a warning message is output saying that setState is being called before a component mounts. Presumably this means that an action is being dispatched on a Controllable before it has mounted (since the default dispatch calls setState()).
Need to debug and figure out what's happening.
Add Lerna to the project to manage shared module dependencies and allow cross-module linking.
this is a weird global import. I'd prefer to actually import { describe, it } etc in each file and be explicit. mocha is the only exception to that pattern currently.
What it says. The goal is to provide unopinionated, render-agnostic components that provide clean, easy render prop decorators to augment user input controls with state management, validation, and mutual interaction orchestration (e.g. two fields whose validation depends on the state of the other).
current:
box(reducer, key)
would be more readable as:
box(key, reducer)
this requires a major release because it is a breaking change. all dependent code will need to be updated.
Subscription in Subscribable.tsx checks to see if the passed children are a function, and if so, calls it. However, for some unfathomable reason, I decided to check arity (fn.length === 2) which means that any children that don't care about dispatch (the 2nd parameter) will not get called.
Remove the arity/length check in isSubscriberChildren().
Automatically generated changelogs can only be kept sane if commits are isolated to a single module. For example, changing stately-react may require upstream changes in stately-async, but the commit message for stately-async needs to be independently clear; that is, it should only reference API changes or additions that are relevant to its own code.
To achieve this, changes that span multiple modules need to be split into separate commits - one per module. Commits that span multiple modules should be rejected, forcing the developer to create a separate commit for each module change.
stately-reducers is fairly intuitive once you understand it, but it would be better with a diagram - for example something like:
MERGE BOX CHAIN
|-- a1
|- a ------|-- a2
| |-- a3
<----- |- b -- ...
|- c -- ...
since REST is (in theroy) fairly standardized, it should be possible to create a <REST endpoint={} > component that automatically targets the given location with GET/PUT/DELETE using the standard route configurations. You'd definitely need to be able to configure it pretty heavily though, since almost no one actually uses REST to spec.
release.sh has a "pause" before actually publishing the package to NPM. this is great for humans as it's one last chance to make sure you didn't do something stupid, but if release.sh were called by an automated CI/CD, it would be preferable to just skip the "pause". adding a -f param would allow a CLI to skip the last-second verification step.
One or more ObservableHQ Journals showing live snippets of React code using various Stately tools would be very useful for documentation purposes, as part of a usage guide.
A contrived example for each of the three major components would be helpful - Subscribable, Controllable and Async.
more advanced and interesting real-world examples would be helpful as well, such as a search bar and a form (complete with read, create, update, delete). The AsyncOperations that are given could communicate with browser storage or the ObservableHQ platform instead of calling real APIs.
once the docs are up on GitHub Pages, it should be easy to rewrite the code examples in the READMEs using <code> blocks and <a> tags. This way, in a snippet like:
<Subscription>
<Subscriber>
{ ...
Subscription and Subscriber would be links that dive into the TypeDoc API docs.
I want to see how Jest compares to Mocha in practice; I've heard good things, and the syntax should be similar. Jest also has support for nice VSCode plugins etc, and is generally becoming more popular.
A big feature. Needs definition; loosely, the goal is to provide a component following the Controllable pattern that allows the recording of action and state history for a subset of the state tree. This would allow replayability and undo/redo in the front end.
use shields.io to create version badges for the latest versions of each package in the root README.
<Hoverable<T>>, <Selectable<T>>, <Openable<T>> ...
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.