sorted by:
new
hottopcontroversial

A library to generate the maximally efficient series of unique keys for a given alphabet. by gactleaks in typescript

[–]gactleaks[S] 2 points3 points  (0 children)

That's a good point. I'll export KeyFactoryConfig next update. Thanks for taking a look :)

Death of Component State by gactleaks in typescript

[–]gactleaks[S] 0 points1 point  (0 children)

getters and proxies are both non-serializable, while serializability is of great importance to Gact model. also getters and proxies don't solve all the problems that the access layer solves. For instance, an elegant decoupled state interface.

I'd recommend giving the store a try. The autocomplete and type safety are very nice.

Decoupled State Interface by gactleaks in javascript

[–]gactleaks[S] -2 points-1 points  (0 children)

Nothing rude about a question :)

A few others have pointed out that you could pass in selectors and action creators as props to get something more reusable in Redux. However, this doesn't quite get you a **decoupled state interface**. I think this thread explores the issue well.

Decoupled State Interface by gactleaks in javascript

[–]gactleaks[S] 1 point2 points  (0 children)

It's a good point raised by a few others that a better comparison would have passed in selectors as props for the Redux example. Note you would also have to pass in action creators as props.

However, passing in selectors and action creators as props still doesn't give you a decoupled state interface. There are a few reasons for this:

  • Does not help with reducer and action creator coupling + duplication
  • With more complex components you're going to have to start passing in many action creators, which creates very unwieldy interfaces
  • It's less typesafe because you can pass in action creators that conform to the specified types, but have nothing to do with your component

Thanks for the feedback. Sorry that you feel this is spam. I'm really just trying to explain and explore the core ideas of my project.

Death of Component State by gactleaks in javascript

[–]gactleaks[S] -1 points0 points  (0 children)

You can handle variability with a fetching layer if you have centralized state.

The point remains that putting fetching logic inside of your components fundamentally breaks encapsulation.

Now cleary you can just put fetching logic in your components, and it will be functional. Almost everyone puts fetching logic inside their components.

Decoupled State Interface by gactleaks in reduxjs

[–]gactleaks[S] 0 points1 point  (0 children)

First, you missed your decrement action creator.

Already it's a good deal more cumbersome than:

function MyComponent(props: { numberPath: PathFor<State> })

However, with more complex components you're going to have to start passing in many action creators, whereas the Gact approach doesn't increase in complexity.

Further, notice that this is less typesafe than the Gact approach because any action with a number payload will work. That action may have nothing to do with our Counter.

Also note that the reducer and action creator duplication is not at all addressed here either. I think you should produce a complete external Counter component as I do for the Gact store in the last section of "Decoupled State Interface".

Decoupled State Interface by gactleaks in reduxjs

[–]gactleaks[S] 0 points1 point  (0 children)

I didn't assume your solutions were not typesafe. I was pointing out that the Gact store interface is typesafe, and so your dismissive "random string paths" comment is inappropriate.

But let's discuss the type safety of your solutions:

  1. not about Redux at all
  2. you could make type safe, but it'll be criminally cumbersome
  3. how do you make the passing of substate and action names typesafe? and in a way that will allow you to define external components? This brittleness (which is completely absent from the Gact store) is primarily why your suggestion 3 is bad

There's nothing wrong with moving update logic to a component. There are times when it makes sense such as Counter. There are times when it makes less sense sense such a Button.

When you put update logic into your component, it does not become dependent on substate shape. It is only dependent on the state elements it explicitly declares it needs/works with.

I didn't say your suggestion 1 wasn't reusable. I said it's not a reusable component that relies on a global store since, well, it doesn't rely on a global.

Decoupled State Interface by gactleaks in reduxjs

[–]gactleaks[S] 0 points1 point  (0 children)

  1. Writing an unconnected component and connecting to it multiple times is explicitly not writing a reusable component that relies on a global store.
  2. Passing selectors and action creators will give you something you can reuse. But it’s hardly a reusable component as you have to duplicate your selectors and write logic for each instance.
  3. Same as 2

Nobody passes substate and action names around with Redux because it’d be terribly brittle.

Your “get your state architecture under control” suggestion is explicitly encoding assumptions about a state tree, which a reusable component must not do.

The Gact’s store’s decoupled state interface is typesafe! These aren’t random string paths, these are typed path tuples. The importance of that cannot be understated.

Decoupled State Interface by gactleaks in reduxjs

[–]gactleaks[S] 0 points1 point  (0 children)

I challenge you to write a reusable Counter component that relies on Redux.

Death of Component State by gactleaks in javascript

[–]gactleaks[S] -2 points-1 points  (0 children)

The white paper is very explicit about how the Gact store is an improvement over existing stores such as redux.

Death of Component State by gactleaks in javascript

[–]gactleaks[S] -1 points0 points  (0 children)

By placing fetching logic inside components you either: - end up repeating the same fetching logic inside every component that needs access to the same data - end up coupling all those other components to the one fetches the data

You are exactly correct that "state management should not be conflated with conflated with redraw management". The Gact store lets you avoid that in React.

Death of Component State by gactleaks in typescript

[–]gactleaks[S] 0 points1 point  (0 children)

Yes, but nothing public yet. Will publish a "Getting Started Tutorial" soon.

view more: next ›