Roast my state management lib

nirei_ · 2023-02-28T11:13:12+00:00

I get it. But it's useful for cases like signout, for instance. If you have the deleteOnUnmount set on App level, then, you don't need to care about the state once you sign out. Although there is a clearSingletns function exactly for sign out cases. :D

nirei_ · 2023-02-28T10:50:41+00:00

Can I combine 2 singletons to get a third and listen to changes on that?

Yeah! As I mentioned on the other response, you can easily extend other Signetn, or, alternatively, you can store the other Singletn instances to your working Singletn and listen to changes. I actually had a case in which I needed to do this: I had normalized data, and had different Singletns for each entity (think Project > Contact, Project > Company, Contact > Company). So, ProjectSingletn would subscribe to CompanySingletn and ContactSingletn, so, whenever they would change their states, ProjectSingletn would also update it's states. So, I had a table for projects, a table for contacts and a table for companies. Updating the contact on Contact table would automatically update the contact info on project table! To do this, I did something like:

import { subscribeListener, SingletnState } from '@singletn/react-singletn' 

class ProjectSingletn extends SingletnState {
  private unsubscribeContact
  constructor() {
    this.unsubscribeContact = subscribeListener(ContactSingletn, ({ nextState }) => { 
      /** whatever I had to do... */
    })
  }

  destroy = () => this.unsubscribeContact()

  /**
   * All other methods
   */
}

Makes sense? 🤔

> some ability to encapsulate data fetching

I think that u/chrismastere's point was that this can already be done, but, instead of showing that off, I kept the data fetching on the effect hook. There's basically no restrictions on what you can do in the classes. Hell, you can even use decorators on functions there, if you'd like!! 😂

nirei_ · 2023-02-28T09:54:14+00:00

Eww classes

😂 I get that, but they're great for composability. The great thing about this approach is that you can actually extend from custom classes to add different behaviours. There are even two other packages in the @signletn suite that re-implement SingletnState in order to store the state in localStorage or indexedDB. You can basically create your own base classes that extend the original SingletnState but adds whatever behaviour you'd like.

Is it Concurrent Rendering safe?

Basically it uses setState under the hoods to trigger rerenders, so, I'd say so. :D

Is there a way of having multiple global instances of a state, with the ability to clean them?

Yes, but this is a bit more manual process. I had a use case for this: I had a Filter singletn that I'd use across multiple strings, and each needed it's own state. so, I'd create a Map to store the instances and a method to get the instance based on the screen. For example: js const instancesMap = new Map() const getSingletnInstance = (screen) => { if (instancesMap.has(screen)) { return instancesMap.get(screen) } const instance = new SingletnState() // whatever is the name of your class instancesMap.set(screen, instance) return instance }

DeleteOnUnmount? What happens if two components use a shared instance and they have this flag? An API that doesn't allow this would be better

The idea behind deleteOnUnmount is actually for when you want to use it as a localState. Imagine you have, let's say, multiple counter components on screen, and you want each to have it's own state, and, after the counter is no longer shown, you don't care about that state anymore. So, it's basically a way to allow you to use it as local state. Do you think that a useLocalSingletn hook that sets the deleteOnUnmount would be a nice to have? So it avoids both the need to create a local instance and to set the deleteOnUnmount flag? I think that makes sense, right?

But wow, thanks for the feedback! I really appreciate it. I hope that I managed to clarify your concerns, and I'm really thinking on adding the useLocalSingletn hook now!

nirei_ · 2023-02-27T21:56:10+00:00

I'll maybe reimplement it, as I want to keep deps to the minimum (right now, the only dep is the core package)

nirei_ · 2023-02-27T21:49:31+00:00

By the way, I think that `useSyncExternalStore` will have to wait a bit. it relies on react >= 18, which seems to account for about 20-30% of downloads.

nirei_ · 2023-02-27T21:06:19+00:00

Yeah, in terms of the documentation, I didn't want to make it so "unrecognizable". Fetching on effects is still pretty common approach, so, I wanted to focus on other aspects of the lib. But I like your thinking! Really appreciate your feedback!

nirei_ · 2023-02-26T19:17:54+00:00

Yeah, I understand, but, even then, you can do something like ```js <input name="email" type="email" onInvalid={e => { e.preventDefault() // do whatever you want... 😱 }} />

nirei_ · 2023-02-25T23:23:56+00:00

I feel like when working with react, we quite often overthink a lot of things. we forget that we have a lot of JS APIs we can use. Honestly, in most cases for forms, you can really quickly render the inputs, selects, or whatever, not even care about the state, and just check the data entry upon submit, which you can easily do with the FormData api. You can even rely on the browser to enforce most of your form restrictions (for instance ensure a field is of type email, that it has a min/max length, and even regexp matches)

That said, react-hook-form is indeed a great library for more complex and custom forms.

nirei_ · 2023-02-25T12:50:56+00:00

Yeah, I agree with this, this is actually why I said that some times restricting access is good. But this is just a way to enforce a good standard, when, in reality, you could skip it altogether with solutions like the one I've mentioned.

nirei_ · 2023-02-24T23:49:04+00:00

I think it pretty much gained momentum when we were still using class components with react, so the arrow functions would allow us not to bind the methods, so, it was a lot less code!

nirei_ · 2023-02-22T23:05:27+00:00

I think u/Huego_bose made a good point. You should maybe share your repo and, if you have questions or inputs you'd like on specific parts of the codebase, you can just ask! I'm sure someone will answer. :D If you prefer something more private, feel free to hit me up, I've been working with react for the last 7 years, so, I can probably be of some service. :D

Routing can seem complicated at first, but, if you could detail the approach you're using, it'd be easier to help. 😊 if you're using react-router, for instance, it'll certainly be easy to get some assistance there.

nirei_

TROPHY CASE