[QUESTION] Why is component B not being re-rendered ...?

[jdvivar]

... after component A has updated the state in this simple example? https://glitch.com/edit/#!/lit-element-state-demo

The issue is resolved in that particular code just by swapping the order in which the definitions of components A and B are loaded. However, the real scenario I have in my app is that, no matter the order, if an asynchronous operation takes some time, when it ends, it doesn't notify the other components of the state change.

What's your opinion about this issue? Is this a bug or should I use LitState in some other way?

[gitaarik]

If you're dealing with asynchronous data, you should take a look at asyncStateVar. It's a special kind of state var for handing with asynchronous data.

And you can always set a loading state manually, yourself. When some async function ends, update the loading states, and the apps that use those loading states will rerender accordingly.

I'm btw in the process of updating both LitState and asyncStateVar. So hold on a little bit. I'm trying to make the docs work.

[gitaarik]

I updated them both now. The readme and docs are all updated. Check it out. If you have any questions let me know.

[jdvivar]

I'll check on the weekend and let you know, thanks for your prompt response :)

[gitaarik]

Hey @jdvivar, I see that you changed to Redux (https://github.com/jdvivar/wheres-our-car-app/commit/edba5bc5c20da26e6b58433cdb3c4922455aa86c), may I ask what your motivation was? I would like to know what you were missing from LitState.

[jdvivar]

There is no objective answer, so I'll try to give you a subjective one, since I think you might be interested in developer experience.

I can work out the solution with Redux, so the only reason I might come to a library like this is for simplicity: less code and a straightforward solution. It looked nice!

In my opinion, it really doesn't live to my expectation (in my Glitch example) that if you do: state.isAuthenticated = true, this change is not reflected in the other component that shares that state property.

Nevertheless I still gave asyncStateVar a go: without reading any documentation, in my example in "state.js", I changed the "stateVar" instances with "asyncStateVar". They're called the same so it just makes sense you can interchange them, right? Nope, it didn't work either! After reading your documentation I realised I had to implement a setter and a getter at the same time that I declared the state variable, which is just a completely different architecture.

At this point I realised if I wanted to use LitState I really had to invest time now... just the opposite of what I was really looking for when I came here. Why not using Redux Toolkit then?

I think with LitState (and asyncStateVar) I can't really reduce the code complexity less than this: https://glitch.com/edit/#!/lit-element-redux-toolkit-minimalist-example

[jdvivar]

I might pivot again though, I'm using the "wheres-our-car" project as a lab for experimentation.

[gitaarik]

In my opinion, it really doesn't live to my expectation (in my Glitch example) that if you do: state.isAuthenticated = true, this change is not reflected in the other component that shares that state property.

Did you use the observeState() mixin on both components? When you use that mixin, then any stateVar variable that you change should be reflected in the components that use this mixin.

Nevertheless I still gave asyncStateVar a go

The asyncStateVar is meant for when you have data that is get and set through an asynchronous function. Therefore you have to define getter and (optional) setter methods that return promises.

Also asyncStateVar is in a separate library now since a while. It used to be part of LitState, but I made LitState extendable and moved asyncStateVar to a separate library to keep LitState small and simple. So if you want to use asyncStateVar you need to install it with npm install lit-state-async-state-var.

Though I don't think you need asyncStateVar. I think I misunderstood your initial question.

Your Glitch example would look like this with LitState:

https://glitch.com/edit/#!/green-glistening-truffle

[jdvivar]

I'm completely lost now... 😅

Can we please roll back to square 1?

Why do you think this example doesn't work? It's still the same example I used to start the discussion, unchanged. And yes, it's using observeState mixin, as you can see: https://glitch.com/edit/#!/lit-element-state-demo

[jdvivar]

Please note, as I said in the first message, the example will work fine just by changing the order in which the modules load in the HTML.

[gitaarik]

Hey, sorry for the late reply, I was busy last week.

Sorry, I didn't see the glitch link in your first message. This glitch uses an older version of LitState, 1.5.2. I updated your example to 1.6.0 here:

https://glitch.com/edit/#!/broad-burly-backpack

It seems to work fine for me now.

[jdvivar]

I cannot see your example, the Glitch you shared gives a 404. I've updated the pakage definition to use version 1.6.0 as you suggested and it still doesn't work as expected:

[christophe-g]

I think stateVar() returns a function (element => {...}), the one you see stringified in Comb B.

try

import { LitState, stateVar } from 'lit-element-state'

class State extends LitState {
  static get stateVars() {
        return {
          isAuthenticated : {},
          email: {}
        };
    }

  // isAuthenticated = stateVar(false)
  // email = stateVar('')
}

export const state = new State()

[gitaarik]

Ok, I understand now why my Glitch projects get removed. Without an account Glitch removes your project. I created an account now. Here is the updated working Glitch project:

https://glitch.com/edit/#!/spice-whimsical-popcorn

[jdvivar]

Ah, so the problem was down to the fact that I was not using decorators and I was doing it wrong 🤦‍♂️

https://gitaarik.github.io/lit-state/build/#basic-usage/no-decorator-usage/

It makes sense now, thanks!

[gitaarik]

Ok great, I'm glad that it works for you now.

Note that I just released a new version where you define the stateVars just a little different. This decision was made because of the discussion here. Check the changelog for information about the changes.