Any plans to add d.ts, or happy if someone else will create it?

Some operations, like array.sort do mutate original value.
I know, that you are aware of it, but why do you returning muted value, not mutated copy of the value?
Current approach probably could poison render, as long it may change value during the render.

Readme.md

Documentation ·
Contributing!

  <a href="http://docs.slatejs.org"><strong>Documentation</strong></a> ·
  <a href="http://docs.slatejs.org"><strong>Contributing!</strong></a>

those links are right ❓ or

• Superlink

  <a href="#documentation"><strong>Documentation</strong></a> ·
  <a href="#contributing"><strong>Contributing!</strong></a>

Helpful for implementing progress bar-like state changes, where you don't want to have to worry about going over a certain number.

Right now the values are limited to being a single point in the render tree. But it's fairly common to end up needing to use the same value in two places, and have them stay in sync. This can be solved with "context", or with things like Redux, but they're all kind of overkill.

It would be cool if this library exposed factory functions for each type of value, so that you could create your own "connected" values. For example:

import { createBooleanValue } from 'react-values'

const ReadonlyValue = createBooleanValue(false)

<App>
  <Content>
    <ReadonlyValue>
      {({ value, toggle }) => (
	    ...
      )}
    </ReadonlyValue>
  </Content>
  <Sidebar>
    <ReadonlyValue>
      {({ value, toggle }) => (
	    ...
      )}
    </ReadonlyValue>
  </Sidebar>
</App>

It would give you a component that has the same interface as the usual <BooleanValue>-style components, but maintain its state across multiple render locations. And it would also expose the transforms as static methods, for convenience, like ReadonlyValue.toggle().

Pretty sure this would eliminate like 90% of the use cases people end up "needing" to move to a global store like Redux/Mobx for.

In my experience it is common to pass set from Any down to the components, but the value will be updated on every value change, as long it is creating on every render.

Probably, creating some factory to produce Component with memoized callback is a better way, and it shall not increase the size of this library.

like

const ArrayValue = produce({
        speread: value => value,
        actions: {
           first: value => value.value[0],
           last: value => value.value[Math.max(0, value.value.length - 1)],
           clear: value => () => value.set([]),
           concat: value => proxy(value, 'concat'),
           fill: value => proxy(value, 'fill'),
           filter: value => proxy(value, 'filter'),
           .......
      }
    })
)

Hi @ianstormtaylor!
Right now it is not convenient to use this library with babelify/browserify, since that uses ES6 export and requires global browserify transform.
Changing main entry in package.json to dist fixes this problem, also that is well-established practice.

Appreciate your attention.

Right now, the convenience transforms are "smart" in that if you do:

<NumberValue>
  {({ increment }) => (
    <button onClick={increment} />
  )}
</NumberValue>

It will fail because it's actually being called as increment(event). Instead you have to write it as:

<NumberValue>
  {({ increment }) => (
    <button onClick={() => increment()} />
  )}
</NumberValue>

But this is such a common use case that it might be nice to either ignore Event objects specifically, or just ignore anything that isn't a "valid" value.

It's also easy to forget this, because onClick={toggle} or onClick={clear} works since they don't care about the event argument in the first place.

How is it different from react-powerplug ?
What are the pros of using react-values over react-powerplug ?

Once hooks reaches the non-beta branches, react-values should expose themselves as hooks. And eventually we can deprecate the render prop approach.

Using <AnyValue> feels awkward in most places it's used, since it's usually when you don't care about the type. Which, 90% of the time, is when you happen to be using strings, but more in an "enum" sort of use case—for things like state machines.

Instead it would be nice to just call it <Value>.

I don't have a horse in the race, but this project seems derivative of react-powerplug. Should perhaps have some attribution? Only seems fair to me

Edit: i could of course be wrong. In which case please ignore :)

I think it would be helpful to have a disabled prop that each of the components respected. When disabled no transforms take effect even when called. Makes it easy to "disable" any component that way without having to check some other state each time you want to transform.

Using <BooleanValue> to control whether a modal is open, which holds a form to update data rendered in a table rows with react-table. Default rows render with an expander closed, so the BooleanValue isn't rendered.. until the row is expanded.

After an async data update, my parent component re-renders the table..

I'm generically closing the modal with set(false) whether the modal was closed simply with a Cancel, or an actual re-rendering data update.

On re-render the <BooleanValue> is not rendered since row is not expanded.

Of course that generates this error:

Can't call setState (or forceUpdate) on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in the componentWillUnmount method.
    in BooleanValue

Is this something that should be handled internally within this library? Then we don't have to worry about tracking mounted state or rewrite separate logic for different toggling use cases...

If component is gone, then these mutate operations could be no-ops...

This would be similar to <MapValue in terms of the convenience transforms, but for operating on plain objects instead.

Great useful , Could you add a h2|h* to readme.md for translate plan

source

## Translations

- [![china](https://raw.githubusercontent.com/gosquared/flags/master/flags/flags/shiny/24/China.png) **中文/Chinese**](https://github.com/chinanf-boy/react-values-zh)

Translations

• 中文/Chinese

you can check https://github.com/chinanf-boy/react-values-zh

What would be the correct way to style a component based on whether a react-values hoc had the disabled property set? It really looks like you can only access the value but maybe there's nothing wrong with leveraging closure to get at whichever variable is used to set disabled?

Is there an <ArrayValue /> example I could see where push is done ? My array changes but no re-render happens when I do a push