raj

This is the version 1.0 release of Raj.

This means Raj is 100% recommended for projects that need a JavaScript framework. The hard problems have been solved. There are strong stories for how to handle side-effects, lazy-loading, code-splitting, routing, composition, and subscriptions. Enough real-world applications have been built; in-house, personal, and open-source. There is package documentation, an in-depth tutorial, and a time-travelling debugger.

Raj and its ecosystem have been under active development for over a year now.
Raj is an implementation of the Elm architecture that feels natural to JavaScript developers.
We retain the strengths of the architecture and leverage JavaScript's dynamic nature to enable powerful composition that Elm itself cannot match.
In areas such as code-splitting and lazy-loading, Raj excels with the JavaScript ecosystem whereas Elm is just scratching the surface.

Raj enters the JavaScript framework war with stand out characteristics:

• Small size; perhaps the smallest legitimate framework. Raj is very easy to add into an existing project.
• View layer independence. React, Preact, and the vast ecosystem of html = view(data) libraries work with Raj.
• A compelling story for dealing with side-effects built into the framework.
• An a-la-carte approach with recommended libraries for common things as opposed to batteries included.
• A pattern of packaging side-effects, business logic, and views together as programs without coupling those concerns.

Quite a few great applications have been built with Raj.
Hopefully, there are a lot more to come.

From Chris:

Cutting this release after a year in development was not a rushed decision.
Raj has been able to meet challenges in building a wide variety of applications.
Raj has been able to amass an ecosystem of libraries that do not hack around it.
This release has been cut because Raj is the right tool to build applications.

I believe it is the best JavaScript framework out there today.
Making this 1.0 release means when a framework is needed, I can recommend Raj without hesitation.

Improving the README and making sure it renders on npm adequately.

See #29 for details.

This is a breaking change.

import { program } from 'raj/runtime'
// becomes
import { runtime } from 'raj'

See #28 for a description of the changes.

This release removes the setTimeout from the runtime. This release will also put the updated README on npm as it has been awhile since a release. See PR #26 for details.

This is a breaking change. I have not experienced the breakage myself on a lot of projects I've tested. If anyone has regressions, I am very interested: please report it.

Edit: By the way, the first commit to Raj was exactly a year ago. It's crazy to think how far this framework has come and how well something so tiny has fared in building complex applications. I'm really excited for a 1.0 which should happen really soon.

This release simplifies done. Before:

function done (model) {
  return () => {
    // call cleanup code
  }
}

After:

function done (model) {
  // call cleanup code
}

See #18 for details. In short, we don't need the complexity of returning an effect.

This release brings a way to end runtimes created via raj/runtime program and also cleanup subscriptions in programs. These changes are explained in PR #13.

The past few weeks I have been working on a few applications with Raj. I like where things are going.

raj-compose

Things were taking shape and raj/effect was growing to be a chokepoint for the development of raj-spa and the applications which used it directly. I broke raj/effect into its own module raj-compose to better tackle composition problems without conflicting with core development.

Migrating:

// BEFORE
import {map, batch} from 'raj/effect'
map(callback, effect)
batch(effects)

// AFTER
import {mapEffect, batchEffects} from `raj-compose`
mapEffect(effect, callback) // NOTE: arg order reversed
batchEffects(effects)

raj-react

React has been a first-class citizen since the beginning of Raj development. Raj has always been view library agnostic and breaking React support into a separate module makes that clearer.

Migrating:

// BEFORE
import {program} from 'raj/react'

// AFTER
import {program} from 'raj-react'

These packages and raj-spa are now listed in the README "Ecosystem" section.

This release changes the raj/react syntax. The init is no longer a function that receives props. See the justification for this change in PR #9. What this means for developers is that,

function init () {
  return [model, effect]
}
// becomes
const init = [model, effect]

And React components are built like:

import React from 'react'
import {program} from 'raj/react'

program(React.Component, props => ({
  init: [state, effect],
  update: (message, state) => [state, effect],
  view: (state, dispatch) => {}
}))

This change makes the ecosystem more consistent for things like raj-spa.

This release removes the raj/message module. The reasoning for the change is in PR #8.

For an almost drop-in replacement for the module, try tagmeme; it is raj/message, just better and stricter.

This patch release changes raj/react to accept the Component class directly as we never really needed the whole React, and variants like PureComponent can now be used. In the raj/runtime, we also renamed the "renderer" argument to "view", aligning with the React binding style view(state, dispatch).

This patch release adds the raj/effect module which contains helpers for working with effects. Also, the React bindings have been decoupled from the runtime, which now lives in raj/runtime. With this decomposition in place it will be easier to break out React support into its own project and support more view libraries in the future. Until then, React integration tests have been written for the bindings.

This patch release changes up some syntax which took some thought.

The init() and update() are now consistent with each other and removes ambiguity from their return arguments. Both functions now must return an array of [newState, optionalEffect] always and the shorthand return of newState is no longer supported. The shorthand would have been a concern if newState were an array. Also when testing an update() or init() the developer would have to know the implementation details of the init() or update() to know how to test the shorthand versus full. Without the shorthand, testing is a lot more clear.

Also, the first argument to update() is now the message, the current state is second. This decision was made because more often than not the state is derived from the message and may not even need to rely on an existing model. So when testing calling update(message) is more appealing than update(null, message). This also has implications for currying if anyone is into that.

This patch release adds plenty of assertions to Raj to prevent misuse with better error messages. You know must also pass React directly to the React bindings; this makes it easier for you to use a custom version of React (if anyone actually does that).