buildo / revenge

DEPRECATED use React.PureComponent and react-skinnable instead

DEPRECATED

use React.PureComponent and react-skinnable instead.

A collection of small React Component helpers

@pure

mark a Component as pure (perf)

import { pure } from 'revenge';

@pure // will add a default shouldComponentUpdate implementation
class UserCard extends React.Component {}

@skinnable()

split logic and rendering (testability)

import { skinnable } from 'revenge';

@skinnable() // or @skinnable(mytemplate)
class UserCard extends React.Component {

  getLocals() { // logic here
    return {
      name: this.props.user.name;
    };
  }

  template(locals) { // rendering here
    return <p>{locals.name}</p>;
  }

}

@skinnable(contains(Component))

wrap "template" components in a "smart/container" component

import { skinnable, contains } from 'revenge';

const UserCard = ({ name }) => <p>{name}</p>;

@skinnable(contains(UserCard))
class UserCardContainer extends React.Component {
  getLocals() {
    // ...complex logic to obtain data...
    return { name };
  }
}

revenge's Issues

avoid pushing or publishing the repo without a fresh build

we must enforce somehow the npm run build script execution

properly reject av Promise on error

@pure decorator potentially dangerous?

"pure" name is misleading: it could be applied to a component which is not pure. the decorator simply states that the component will be optimized with a default shouldComponentUpdate method relying on references

add @log util decorator

@log
function sum(a, b) {
  return a + b
}

sum(1, 2); // prints to console: "sum(1, 2) => 3"

better handling of null values in App.get()

missing dependency: tcomb-react

used by props decorator

Write a eslint rule to avoid this.props usage in template() methods

make batch debounce delay configurable

simple loading decorator for v0.1.x

temp readyState

autobound decorator shouldn't be included?

In order to maximize the benefits of PureComponent

remove Query.js

serializable App cache

Presentation Comments

3-6-15

avenger things

• opt-in statefulness
• query state cascade should be available stateless, segregated from total state (e.g.: on a server)
• optimizer should be able to run client side or server side or isomorphic side
• via lo stringame from query deps declaration
• luca is concerned about separation of state partitions

revenge:

• graphics guy and @skinnable
• named arguments API for Query 7826c07

v0.1: don't complain for duplicated query ids

@anonymous redirect shouldn't handle `/`

nextPath=%2F breaks https://github.com/buildo/labonline DefaultRoute

rename build directory to lib and add an index.js file

I think it's a standard to provide a ready to go package on npm:

src       # ES6
lib       # transpiled files (ES5)
index.js  # npm package entry point

fix readyState loading

• In readyState, loading and cache are always false because it's checked a property of a String
• loading should be true when at least one query is loading

v0.1.3

Can we have an official branch with v0.1.3 ?

fetch state and caching data inside components

Requirements

1. users (components) need to be able to know the fetching state of required data (loading, done, error)
2. users (components) need to be able to keep stale data rendered, for UI (visual and performance) purposes

Specs TBD

1. I'm planning to add a global fetch state in revenge and to provide components using @queries with an additional fetchState or similar prop (basically 'loading'/'done'[/'error'?]).
   Fine-grained per-single-component-@queries fetchState can be kept by revenge itself looking at queries incrementally providing fresh data
   When avenger is in a better shape, this should definitely be part of it (so that we can have a proper fine grained control over what's happening)

be sure to have a read at this first: http://facebook.github.io/relay/docs/guides-ready-state.html#content

1. Currently "refresh" behavior (for a non cacheable query): queryData -> null -> queryData
   This can stay the same (just change cacheMode if you want to skip the null), but I see less and less practical uses for cacheMode=no queries

@utaal @gcanti @francescogior additional thoughts?

perf: @pureFunctions decorator

requirements:
use @pure (and potentially any other pure-render tool) correctly when props involve .binded and/or partiallly applied functions
i.e: avoid unnecessary re-renderings
see e.g. this for reference: https://discuss.reactjs.org/t/using-function-bind-and-purerendermixin/655

spec proposal:
@pureFunctions decorator, to be used on top of @pure
should let you pass to @pureFunctions-decorated components functions as:

onClick={[myFn, myArg1, myArg2]}

instead of

onClick={myFn.bind(this, myArg1, myArg2)}

and handle properly the reference for the underlying @pure component: reuse cached fn references when fn and args are unchanged

This gives big perf improvements e.g. on LOL/SamplesList for cellRenderer and SampleCard.onClick props

@FrancescoCioria @francescogior thoughts about the syntax?

run avenger Commands

react-router-transition-context

warn for improper usage of decorators

e.g.

• @log without ()
• @anonymous

update avenger dep

publish on npm v0.1.1

exit the promise internalTryCatch before emitting data events

remove PureComponent

the @pure decorator should be enough. Moreover it will be possible to freely extend a custom class

change Query API from positional to named arguments

Before

new Query(
  'queryUser',
  () => return this.db.getUser(userId),
  () => return this.API.fetchUser(userId),
  ['queryConfig']
);

After

new Query({
  id: 'queryUser',
  get: () => return this.db.getUser(userId),
  fetch: () => return this.API.fetchUser(userId),
  dependencies: ['queryConfig']
});

authenticated() static check

Just noticed that the iso redirect when no cookie is set doesn't work anymore.
It is likely caused by the issue @gcanti pointed out: static methods not handled correctly by react-router with the current implementation of @authenticated()

Just opening this to get back here if that is not the case

queries.filter should be per-query

currently can cause duplicate query declarations to be filtered out even if only one filter condition is false

better handling of nextPath in anonymous

Should be configurable for remote av recipe execution

add tests

avenger looking for revenge

buildo/avenger#35

add more infos when pure decorator's algorithm detects a re-rendering

update avenger version

is @autobound really useful?

Reading the code of autobound I noticed that the method seems attached to the instance, not to the prototype ... so instead of

import { autobound } from 'web-framework';

class Wrapper extends React.Component {

  @autobound
  method() {
    console.log(this.props.name);
  }

  render() {
    return <Wrapped method={this.method} />;
  }

}

yesterday @gabro suggested something like this

class Wrapper extends React.Component {

  method = () => console.log(this.props.name);

  render() {
    return <Wrapped method={this.method} />;
  }

}

Add a README.md file

review please @gabro @giogonzo

https://github.com/buildo/web-framework/blob/readme/README.md

(optional) custom scu function in @pure

add a LICENSE file

per-params @queries

Add cookieSetter option to CookieSerializer

getState should be app business only

requirements

• more decoupling wrt react router

specs

• just delegate to app impl. state building entirely

collect errors from avenger execution

add name to Query struct

strip if (NODE_ENV != 'production') in preprocessing for prod builds

remove `renderif`

since it's not lazy and thus basically useless / potentially dangerous

add a .npmignore file

something like

.*
*.log
node_modules
src
test

update deps