buildo / revenge Goto Github PK

e.g.

• @log without ()
• @anonymous

• 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

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

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} />;
  }

}

review please @gabro @giogonzo

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

"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

used by props decorator

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

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']
});

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

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?

In order to maximize the benefits of PureComponent

Can we have an official branch with v0.1.3 ?

something like

.*
*.log
node_modules
src
test

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

requirements

• more decoupling wrt react router

specs

• just delegate to app impl. state building entirely

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

buildo/avenger#35

we must enforce somehow the npm run build script execution

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

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?

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