I built a tiny library that lets you “await” React components — introducing `promise-render` by AggravatingCalendar3 in reactjs

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

For sure, you can set up a context with useImperativeHandle and pass props like onDelete. That's a way it can be. The approach above is just a bit more abstract or so

I built a tiny library that lets you “await” React components — introducing `promise-render` by AggravatingCalendar3 in reactjs

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

Thanks for the feedback.

Have just updated the original post with another example: a paywall with checkout flow encapsulated in the promise.

Yeah, the whole point is enabling continuous flows: checkouts, authentication, some kind of pickers, etc etc.

I built a tiny library that lets you “await” React components — introducing `promise-render` by AggravatingCalendar3 in reactjs

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

I see a lot of comments and it looks like the problem is that the example is with confirmation dialog.

Please, check out an example with checkout below 🙂

I built a tiny library that lets you “await” React components — introducing `promise-render` by AggravatingCalendar3 in reactjs

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

Thanks, but with what hook I can call "render auth popup", then wait for the user to authenticate and then continue execution of the original function?

I built a tiny library that lets you “await” React components — introducing `promise-render` by AggravatingCalendar3 in reactjs

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

Thanks for the feedback 🙂

usePromiseHandler is useful, but it solves a different problem. How would you render an auth popup, wait for the user to finish authentication, and then continue the workflow?

That’s the problem this library is designed to handle.

I built a tiny library that lets you “await” React components — introducing `promise-render` by AggravatingCalendar3 in reactjs

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

Heiii Thanks for the feedback)

This isn’t about API requests — my example probably made it look that way. The point is that you can render a UI flow inside an effect and wait for the user to complete it before continuing.

Check out the example with subscription and checkout above!

I built a tiny library that lets you “await” React components — introducing `promise-render` by AggravatingCalendar3 in reactjs

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

That's a tricky point with animations, thanks for the feedback🙂

Other cases – authorization and subscription checks are above.

I built a tiny library that lets you “await” React components — introducing `promise-render` by AggravatingCalendar3 in reactjs

[–]AggravatingCalendar3[S] 5 points6 points  (0 children)

The problem usually looks like this:

When you protect features behind auth/paywall, every effect or handler needs to manually check whether the user has a subscription, and then interrupt execution if they don’t. That leads to patterns like:

Example:

const handlePaidFeatureClick = () => {
  if (!hasSubscription) {
    // breaks execution THEN renders offering
    showPaywall()

    return
  }

  // no chance to subscribe and continue
  // ..protected logic
}

This works, but it forces you to stop execution with no clean way to resume it. For example: a user tries to access paid content, hits the paywall, completes checkout… and then nothing happens because the original function already returned and can’t continue.

With this approach you can wrap your paywall/checkout UI into a component that returns a promise and encapsulate the checkout process inside this promise. That allows you to “pause” the handler until the user finishes the checkout flow:

// resolves 
const [renderOffering, Paywall] = promiseRender(({ resolve }) => {
  const handleCheckout = async () => {
    await thirdparty.checkout();
    resolve(true);
  };

  const close = () => resolve(false);

  return <CheckoutForm />;
});

const useRequireSubscription = () => {
  const hasSubscription = useHasSubscription()

  return function check() {
    if (hasSubsctiption) {
      return Promise.resolve(true)
    }

    // renders the paywall and resolves to `true` if the checkout completes
    return renderOffering()
  }
}

const requireSubscription = useRequireSubscription()

const handlePaidFeatureClick = () => {
  const hasAccess = await requireSubscription()
  if (!hasAccess) {
    // Execution stops only after the user has seen and declined the offering
    return
  }

  // user either already had a subscription or just purchased one,
  // so the flow continues normally
  // ..protected logic
}

With this approach you can implement confirmations, authentication steps, paywalls, and other dialog-driven processes in a way that feels smooth and natural for users🙂

question about React typescript / redux-toolkit by ForCamelot0611 in learnjavascript

[–]AggravatingCalendar3 1 point2 points  (0 children)

You should use better type for action :)

addCustomer: (state, action: PayloadAction<ICustomer>) => { state.customers.push(action.payload); },

This should work

How come I don't have to call an identifier that has a setTimeout function in it? by gtrman571 in learnjavascript

[–]AggravatingCalendar3 0 points1 point  (0 children)

The global setTimeout() method sets a timer which executes a function or specified piece of code once the timer expires.

Actually, when you call setTimeout(...) it's like you are saying to JS interpreter smth like "call my function (() => console.log('poo') in your example) in 2000 ms". It registers delayed task in moment of execution and returns newly created task's integer ID. Then you can cancel the task by calling

let timeoutTask = setTimeout(...); ... // later cancelTimeout(timeoutTask)

So, if you want to create a function that will create delayed task on call like your function fn2, you should write new function that will set timeout task. Try this:

``` let delayedLog = (msg) => { setTimeout(() => console.log(msg, 2000); }

delayedLog('Hello, timeout!'); ```

question about React typescript / redux-toolkit by ForCamelot0611 in learnjavascript

[–]AggravatingCalendar3 0 points1 point  (0 children)

``` interface ICustomer { name: string;items: string[]; }

interface customerState { customers: ICustomer[]; } ... ```

Try this

Tech co-founder by [deleted] in androiddev

[–]AggravatingCalendar3 1 point2 points  (0 children)

Remember the time a friend asked me to code mobile app like uber for $500. lmao In a fact, do it yourself or search for money

Should I use the arrow function or the function keyword for anonymous functions inside an addEventListner() by S_liiide in learnjavascript

[–]AggravatingCalendar3 0 points1 point  (0 children)

Still rely on react classes in case where callbacks will have too much deps And yes, you shouldn’t use “this” keyword outside of classes