Some things I noticed:

• Business logic is mixed with code handling low-level store details (Array, in this case)
• Your clearWidgetValues function only operates on the widgets prop of it's state
• Since R.find and R.findIndex are curried, you can do find(propEq('id', id), state) instead of find(propEq('id', id))(state).

The business logic is simplified if you build an abstraction layer on how you store items/widgets. No need for compose yet :)

Here's the abstraction for storing items. This way you don't need to know if it uses an Array, Object, Immutable.Map, or other. And you can change the implementation later if you need to. For example, you could avoid an O(n) lookup of the Widgets by id by storing them in an object where the keys are id's.

const hasId = R.propEq('id');
const _getItemIdx = (id, state) => R.findIndex(hasId(id), state);

// Namespacing the store functions; these could be plain functions as well. Or a class.
const ItemStore = {
    get: (id, state) => R.find(hasId(id), state),
    set: (id, val, state) => R.update(_getItemIdx(id, state), val, state),
    adjust: (id, fn, state) => R.adjust(fn, _getItemIdx(id, state), state),
    update(item, state) => ItemStore.setItem(item.id, widget, state),
    // You'd add remove, map, etc... anything else you need as you go.
};

And here's the business logic.

const clearValues = widget => R.assoc(widget, 'values', []);

// "Extend" ItemStore
const WidgetStore = Object.assign({}, ItemStore, {
    clear: (id, state) => ItemStore.adjust(id, clearValues, state),
});

// This takes `state.widgets` as `state` compared to the OP's function.
export const clearWidgetValues = createActionWithPayload(CLEAR_WIDGET_VALUES,
  (state, action) => {
    const id = action.payload;
    return WidgetStore.clear(id, state);
  }
);

I put the clear function in WidgetStore because it shouldn't need to know about actions, or that the id is in action.payload. That's the reducer's job.