text:
Initial experimental React 18 compat prototyping

This PR:

Updates our React devDeps to 18.experimental versions, along with React Testing Library's PR build from https://github.com/testing-library/react-testing-library/pull/937
Updates our TS config to use the types for those React builds
Fixes almost all of the failing tests, which were primarily due to state updates being triggered outside of act()
Actually swaps useSelector over to use useSyncExternalStore instead of our own subscription logic
Also updates connect to use useSyncExternalStore, albeit in a kinda sketchy way
Rips out the pure option for connect

@dai-shi has a proof-of-concept PR at https://github.com/pmndrs/zustand/pull/550 that will likely be useful as a starting point.
Status
At this point I see 3 test failures.  Two look like they're related to tests for "avoid setting state on unmount", and the other looks like it's a batching-related issue.  Need to investigate those further.
Note that this so far involves no library code changes whatsoever.  Once I get the current tests updated to be passing based on expected behavior with React 18 overall, the next step is to try switching our logic over to use useSyncExternalState per https://github.com/facebook/react/pull/22211 , and see what happens.
I've just commented out / tweaked those three test failures for now so I can move on. I'll review them more later.
Update 1
I just successfully got useSelector migrated over to use useSyncExternalStore!  I'm seeing one legit test failure atm - uSES is not correctly preserving the previous selected result when you give it a new selector reference, because of how it memoizes things.
I wrote some notes in https://github.com/facebook/react/pull/22211 , and I'll paste those here:

React-Redux currently catches errors thrown from selectors inside of subscriptions, saves them in a ref, and forces a re-render. If the selector runs clean while rendering, no problem. If it throws again, we attach the original error's message to the new error just in case it was two different things that happened. However, uSES always swallows errors in checkIfSnapshotChanged, so we can no longer check the original error ourselves.  I was able to work around this by having useSelector wrap the original selector with one that does a try/catch and saves errors to a ref, but wow is that hacky.
Is the "not a valid React 18 version" check accidentally inverted? It currently says if (React.startTransition !== undefined) {, which seems wrong. I'm currently running 18.0.0-alpha-1314299c7-20210901, which most definitely has a startTransition function defined, and I am seeing that warning printed.
Our test for "checks for updates when subscribing and re-renders if different" is seeing a third render occur, when it used to only see two, and I can't figure out what's causing that extra render to happen (especially since renders 2 and 3 are seeing the same selected state).  My vague hypothesis is that it may have something to do with the test dispatching an action in a useLayoutEffect in a child, while the subscription happens in a useEffect in the hook in the parent?
The way that useSyncExternalStoreExtra's memoization check is implemented means that if you get a new selector function, there's no way for it to be equal to the prior result and reuse it, because all of the memoization variables are internal to the useMemo hook.  Our v7 useSelector does this behavior by keeping around the last selected value in a useRef.  We have a test for that in our codebase, and it's failing atm, and I'm pretty sure this is a "correct" failure based on what I'm seeing in the uSES implementation.

Update 2
I've just gotten connect updated as well, and I've also ripped out the pure option.
I'm not convinced that the way I integrated useSyncExternalStore into connect is at all "correct". connect is still doing all the actual child props derivation logic. It's really just deferring to uSES for the "trigger a re-render" step.
All of the "impure behavior" tests were failing with this approach.  After thinking about it, this option seemed ripe for removal. It only existed because early React ecosystem usage sometimes still relied on external mutable sources that would be different every time the component re-rendered, so we always had to re-run mapState and the props merging logic.  In today's world, that's no longer the case - external mutability is no longer a thing that shows up in codebases, and at this point if you're still doing that it's a bug.
I did run a SourceGraph search to try to find any places where people were actually using {pure: false}. Best I could come up with was https://sourcegraph.com/search?q=context:global+lang:JavaScript+connect(.%2B%2C+.%2B%2C+.%2B%2C+{.pure%5Cs%3F:%5Cs%3Ffalse.%7D%29&patternType=regexp , which only had 59 hits in 1.2M repos. Of those 59 hits, half were FlowType typedefs.  So, this seems safe to kill off, and it simplifies several other bits of the remaining codebase anyway.
At this point, there's two tests failing, and ironically they're both bugs in uSES itself:

It's not correctly memoizing and reusing the last returned value if it gets a new selector reference
It's printing a "no useLayoutEffect in SSR" warning

Now that I think about it, I do have some tests for useSelector that I'd temporarily tweaked and gotten to "pass" by changing the assertions just to let me keep going. I need to review those further.

Hmm. Not sure why the tests aren't running. Created this as a "draft" initially and thought that might be why, but doesn't look like they're running after changing it to a normal PR either.

If you rebase off master, it should have a button for running tests now.

Is the "not a valid React 18 version" check accidentally inverted? It currently says if (React.startTransition !== undefined) {, which seems wrong. I'm currently running 18.0.0-alpha-1314299c7-20210901, which most definitely has a startTransition function defined, and I am seeing that warning printed.

I think this warning is intended since the shim of useSyncExternalStore does not support React 18. The warning should disappear in React 17 or once https://github.com/facebook/react/pull/22239 lands.

It's not correctly memoizing and reusing the last returned value if it gets a new selector reference

This is intentional part of the design of useSyncExternalStore — we always call getSnapshot during render, because it might have been changed by a parent. That's how we avoid zombie props.
The "extra" version of the API supports skipping the additional call during render... but only if you pass the same selector. So it has to be stable/memoized. (The difference compared to useMutableSource is that it won't de-opt to synchronous mode if it renders during a transition, and it won't resubscribe.)
Alternatively, if you'd rather use the zombie props (to preserve Redux's existing behavior, I'm guessing?), you might as well skip the "extra" version of the API and track the latest selector on a ref like you currently do, since our selector implementation won't provide any additional benefit over the lower-level API.

Aside from preserving existing behavior, though, I'd say that for the majority of cases it's fine not to memoize the selector. Especially if they don't pass a custom isEqual argument. Most selectors aren't that computationally expensive.
For those cases where the selectors are expensive, there's a straightforward solution: wrap it in useCallback. You can tell users to think of it as an optimization, similar to other scenarios in React where you'd use useMemo, memo, or PureComponent. But you wouldn't want to do this prematurely everywhere, because usually the impact of running the selector again is negligible compared to the weight of another hook.
This is going to be our advice for useSyncExternalStore in general.

@acdlite I'm not sure I explained the "memoized value vs new selector ref" issue enough here.
When a new selector reference gets passed into useSelector, yes, we do need to call the new selector because it's entirely possible that it could return something completely different than the old one did.  (Granted, 99.9% of the time it's the exact some function code-wise, just inlined.)  However, it's also possible (and even likely) that the value returned from the new selector passes the equality check vs the last returned value.  In that case, we want to still reuse the old memoized value and return it, thus avoiding an extra unnecessary re-render.
What I'm seeing with the uSESExtra implementation atm is that because of how the memoization is implemented via a closure, it's impossible to get a new selector ref and still refer to the old result value to return it.

However, it's also possible (and even likely) that the value returned from the new selector passes the equality check vs the last returned value. In that case, we want to still reuse the old memoized value and return it, thus avoiding an extra unnecessary re-render.

Ah I see, ok I think it makes sense to support that

What would happen if you stripped down the implementation as much as possible? What features is React missing in the current proposal? (Other than not bailing out on equal selections when the selector changes, as discussed above, which we'll add.)
In other words, in what ways would the following implementation be insufficient:
function useSelector(selector, isEqual) {
  const store = useReduxStore();
  return useSyncExternalStoreExtra(
    store.subscribe,
    store.getState,
    selector,
    isEqual,
  );
}

Our goal with useSyncExternalStore is to upstream a lot of the complexity you're currently having to deal with in userspace, so whatever we're missing we'd love to hear about it.
I think the main extra things you currently have are:

a subscription manager that's aware of the tree structure
an error replay mechanism if a selector throws

My understanding is that both of these exist to account the zombie children scenario. However, the useSyncExternalStore is designed to avoid that, so I wonder which of your tests would break if you removed them and tried relying only on useSES?

an error replay mechanism if a selector throws

I think we mentioned this previously, but React actually uses this exact same mechanism for all errors, which we leverage in useSyncExternalStore. So I'm hoping you can rely on that instead of implementing it again yourself.

However, it's also possible (and even likely) that the value returned from the new selector passes the equality check vs the last returned value. In that case, we want to still reuse the old memoized value and return it, thus avoiding an extra unnecessary re-render.

So I remembered why I didn't implement it this way: React doesn't need the reference to be the same to skip re-rendering.
The way bailouts in React work is that, if a component re-renders but none of the state or props have changed, we assume the children are equal even if they fail an equality check.
So even if useSyncExternalStoreExtra returns a new reference, if no other state in the component has changed, then React will still bail out.
If you have a test that asserts the references are equal, then it will obviously fail, but if your test instead asserts that the children don't re-render, then it should pass.
If you find this still doesn't work as expected, could you point me to a failing test so I can take a look?

Sounds good.  And yeah, the currently failing test is at https://github.com/reduxjs/react-redux/pull/1808/files#diff-be963b0f28d22eab25f8f42209afbe9a4f5d16696f016853c310c7832303cdb5R621-R623 :
        it('reuse latest selected state on selector re-run', () => {
          const alwaysEqual = () => true
          const Comp = () => {
            // triggers render on store change
            useNormalSelector((s) => s.count)
            const array = useSelector(() => [1, 2, 3], alwaysEqual)
            renderedItems.push(array)
            useLayoutEffect(() => {
              renderedItems.push(array)
            })
            return <div />
          }

          rtl.render(
            <ProviderMock store={normalStore}>
              <Comp />
            </ProviderMock>
          )

          expect(renderedItems.length).toBe(1)

          normalStore.dispatch({ type: '' })
          act(() => {
            normalStore.dispatch({ type: '' })
          })

          expect(renderedItems.length).toBe(2)
          // TODO This is failing, and correctly so. `uSES` drops the memoized value if it gets a new selector.
          expect(renderedItems[0]).toBe(renderedItems[1])
        })

@acdlite I'll have to circle back to your other questions about "missing scenarios" later when I have more time to think about it.
You can see in this PR that I did some very stupid hacky things to get connect to continue working as-is - mostly the need to trigger those cascading subscriptions inside of the subscription listeners.  Not sure there's anything applicable for uSES out of that, though.
For the error handling, useSelector currently tries to keep the original error from the subscriber around for reference, so that if it happens again while rendering, we can say "error Y may be related to previous error X".  Tbh I'm not sure how fully useful that is, and falling back to uSES's own error handling may be acceptable here.

Since this is not idiomatic Redux and you don't already support it, you could add that as a separate API?

Ok I fixed the memoization issue: https://github.com/facebook/react/pull/22307.
Available in the experimental release channel, starting with use-sync-external-store@0.0.0-experimental-fd5e01c2e-20210913
Lemme know if it works as expected

The idea of an areStatesEqual comparison does have application beyond "we're being bad and mutating the state".  For example, if you know that you're only ever reading from state.x, you could supply (prevState, newState) => prevState.x !== newState.x and avoid any execution of the selectors for this component until you know that state.x has changed.  So, sort of a pre-optimization that could skip the "run the selector" stage entirely.
connect has had that option since v5. I'm not sold on adding it, but since the question did just come up in that other thread, it was just on my mind as a thing that I don't know if we could do with uSES as currently implemented. Maybe we could, if we did some getSnapshot shenanigans, but unlikely it would be worth the effort (especially given that we've gotten along without that option thus far).

@acdlite Just updated all our React devDep packages locally to 0.0.0-experimental-fd5e01c2e-20210913.  Looks like that does pass the "return the last memoized value" test now.
I only see one other current test failure, which is the "no warnings from useLayoutEffect in SSR" test :)
but I do have a couple other render-count related tests I need to go back and review a bit.

Huh.  @acdlite , I clearly have issues understanding how the whole dispatcher thing works :)
unstable_useSyncExternalStore does not appear to be exported by react-dom@0.0.0-experimental-fd5e01ce-20210913. However, it seems like it is made available on the dispatcher, and if I hand-edit use-sync-external-store.development.js to refer to builtInAPI = React.unstable_useSyncExternalStore, and I add a logging line to the uSES function in react.development.js, I can confirm that the built-in API is being called.
In fact, when I do that, I actually see better test results in a way.
When I was doing the first work on this PR earlier, I saw three of our tests that do render counts in assertions start failing because of an extra render pass happening, and I couldn't figure out what was causing it.
If I do these hand-edits to force the use of the built-in uSES, I'm now seeing those tests revert back to the original (and expected) number of renders.  Here's the "failures" with the built-in version that show the reversion to the original behavior:
  ● React › hooks › useSelector › lifecycle interactions › notices store updates between render and store subscription effect

    expect(received).toEqual(expected) // deep equality

    - Expected  - 1
    + Received  + 0

      Array [
        0,
        1,
    -   1,
      ]

      238 |           // 2) Render due to dispatch, still sync in the initial render's commit phase
      239 |           // TODO 3) ??
    > 240 |           expect(renderedItems).toEqual([0, 1, 1])
          |                                 ^
      241 |         })
      242 |       })
      243 |

      at Object.<anonymous> (test/hooks/useSelector.spec.tsx:240:33)

  ● React › hooks › useSelector › performance optimizations and bail-outs › calls selector twice once on mount when state changes during render

    expect(received).toEqual(expected) // deep equality

    Expected: 3
    Received: 2

      427 |           // TODO As with "notice store updates" above, we're now getting _3_ renders here
      428 |           // expect(renderedItems.length).toEqual(2)
    > 429 |           expect(renderedItems.length).toEqual(3)
          |                                        ^
      430 |         })

So, it looks like there's a slight difference in behavior between the shim and the built-in implementation, which is not terribly surprising.
This is interesting. We should want to have our tests run against the built-in version, but I can't just hand-edit the shim file to make it work the way I want to as a real solution.
Also not sure how to handle the difference in render counts here.  Will have to think about this a bit.

I think the issue is just that I useSyncExternalStore is still prefixed, even in the experimental channel, so the shim doesn't pick up the native version yet.
The reason that test fails is because the shim does not work with createRoot. It only works in legacy mode, where updates are always sync.
The idea is that the shim will always pick the native version in React 18, and always the shim in anything below that, because useSyncExternalStore doesn't exist in anything before 18.
The issue right now is that it also doesn't exist in the 18 alphas yet. That's why you get the warning, as @eps1lon explained here: https://github.com/reduxjs/react-redux/pull/1808
(I didn't realize React testing library automatically uses createRoot when it's available. We should ask them (and by "them" I guess I mean @eps1lon) not do that, since there are enough subtle batching changes that it's likely to break some existing tests if they all get automatically switched over when you upgrade React. But this is a perfect example of why we prefix things — people add feature testing for unstable APIs and then when we ship the stable it has the potential break their users. See also: https://github.com/remix-run/react-router/issues/7308.
OTOH if React Testing Library users are already using act everywhere then maybe it'll just work? Doesn't seem like that's the case, though.)
Until the useSyncExternalStore API is finalized, what I'll do is update the shim to import the unstable version. (I should have done that from the beginning, didn't consider this in-between early testing phase.)
In the meantime, you can continue your testing by downgrading React and React DOM back to 17.

(I should have done that from the beginning, didn't consider this in-between early testing phase.)

Well, I kind of did — that's what the warning was for :D

Ok the prefix issue is fixed now, starting with 0.0.0-experimental-806aaa2e2-20210913

I can only assume there's some shenanigans going on with import timing and Jest modules somehow? Perhaps it also has to do with React Hooks Testing Library not being updated yet.

It looks like you updated the react and react-dom packages, but not react-test-renderer. The API is imported from the react package (which is why use-sync-external-store attempts to use it) but the renderer doesn't implement it. If you change the versions to match (either both 17 or both 18) then it will work.

(* I didn't realize React testing library automatically uses createRoot when it's available. We should ask them (and by "them" I guess I mean @eps1lon) not do that, since there are enough subtle batching changes that it's likely to break some existing tests if they all get automatically switched over when you upgrade React.

We specifically do this because you made it clear in your messaging that createRoot will be the default in React 18. It's also a bad impression to trigger warnings by default (ReactDOM.render is deprecated) in React 18.
I want to stress that warnings are very frustrating for library users in test suites since many suites are configured to fail if any warnings are triggered. So "it's just a warning" isn't helpful advise.
So it's a bit odd now to hear that we should not default to createRoot when React itself considers it the default going forward. I'll see if more repositories report integration issues. Though from my impression doing this work in Material-UI we had relatively few places where act() was missing. But that test suite is also maintained by myself so I may have a bit of a bias towards how well act is integrated into existing React test suites.
But the messaging is still a problem in my opinion. I don't have a strong opinion what should be the default going forward. But the ecosystem should agree on one, not many.

Will respond in more detail on the morning, but quick thoughts :

yeah, I need to bump the renderer package
we've been assuming that v8 would require React 18 as a min peer dep, just like v7 required 16.8 for hooks. So, I'd want to stick with 18 for testing. That said, if 16/17 compat is viable, then A) we'd need to figure out a good way to run tests against each version, and B) the tests would have to account for some differences in behavior like batching. Like, I just saw earlier that the shim produces an extra render in some cases than the built-in api does.

createRoot will be the default in React 18

You can default to that for new apps that use React 18, the question is whether you should automatically switch over existing apps to createRoot as soon as they upgrade.
Any updates that aren't wrapped in act are immediately going to break. Though maybe I'm mistaken in my assertion that users of React Testing Library don't already use act everywhere?
My expectation is that most existing apps aren't that rigorous about using act everywhere, because the act warning doesn't fire in all cases. For example, there's no act warning for class-based updates today. Or root-level updates.

we've been assuming that v8 would require React 18 as a min peer dep

Ok that's fine, I wasn't sure if you were going to require a bump or not. Either way the prefix thing is fixed now so if you update the version I think it'll work.

Like, I just saw earlier that the shim produces an extra render in some cases than the built-in api does.

I would try it again, I tried it locally and the only time I got an extra render was when running the shim in createRoot. Which shouldn't happen now that I fixed the prefix thing.

@eps1lon Ah, does React Testing Library automatically wrap all updates in act as part of the framework? In that case, then defaulting to createRoot whenever it's available makes sense to me, I think.

createRoot will be the default in React 18

You can default to that for new apps that use React 18, the question is whether you should automatically switch over existing tests to createRoot as soon as they upgrade.
Any updates that aren't wrapped in act are immediately going to break those tests. Though maybe I'm mistaken in my assertion that users of React Testing Library don't already use act everywhere?

Our APIs are all wrapped in act, yes. Examples that come to mind that probably break are HTMLElement.focus().
Though I suspect that most test should pass. On the other hand, if we default to ReactDOM.render and people let their tests fail if they see warnings, then every test will fail. So the question is which scenario is more common which we're unlikely to answer.

My expectation is that most existing apps aren't that rigorous about using act everywhere, because the act warning doesn't fire in all cases.

That was my impression as well.

We should continue the testing discussion in a separate thread, but my thinking re: the legacy API warning was that you should either upgrade all your tests up front, or if that's not feasible, update your test infra to temporarily silence those warnings until you're able to gradually fix them.
Could maybe publish a codemod, too, though there are so many testing frameworks and patterns idk if that'll work

Hmm. I just pulled down build 0.0.0-experimental-50263d327-20210914 for react, react-dom, and react-test-renderer.  Good news is the useSelector tests all pass now (with the tweak of removing the "expect an extra render" assertions I'd had to change with the shim).
Bad news - now a couple other test files are suddenly failing, because they use react-dom/server and that's throwing a "Not yet implemented" error:
  ● React › server rendering › should be able to render connected component with props and state from store

    Not yet implemented

      712 |
      713 |       try {
    > 714 |         actualChildProps = useSyncExternalStore(
          |                            ^
      715 |           subscribeForReact,
      716 |           actualChildPropsSelector
      717 |         )

      at Object.useSyncExternalStore (node_modules/react-dom/cjs/react-dom-server-legacy.node.development.js:4874:9)
      at Object.useSyncExternalStore (node_modules/react/cjs/react.development.js:1629:21)
      at Connect(Greeting) (src/components/connect.tsx:714:28)
      at renderWithHooks (node_modules/react-dom/cjs/react-dom-server-legacy.node.development.js:5279:16)

Server error is expected for now, just haven't implemented that part yet

Have y’all tried this against @dai-shi’s https://github.com/dai-shi/will-this-react-global-state-work-in-concurrent-rendering yet? Has anyone confirmed that usage of the useSyncExternalStore() API actually mitigates tearing?

Nope, but amusingly someone else brought this up in a React 18 discussion just a couple hours ago :)
I'll add it to my list of things to try, but it would be great if someone else wanted to try that as well.

I just tried running @dai-shi 's tests against this v8 branch. As setup, I copied the existing react-redux test to react-redux-v8, also installed the CSB build from this PR as an alias of react-redux-v8, and updated the React and ReactDOM deps to the same versions I have in this PR.
The results were... interesting:
 FAIL  __tests__/all_spec.js (35.122 s)
  react-redux
    with useTransition
      √ test 1: updated properly with transition (2651 ms)
      × test 2: no tearing with transition (65 ms)
      √ test 3: ability to interrupt render (1 ms)
      × test 4: proper branching with transition (7230 ms)
    with intensive auto increment
      √ test 5: updated properly with auto increment (2220 ms)
      × test 6: no tearing with auto increment (1 ms)
  react-redux-v8
    with useTransition
      × test 1: updated properly with transition (5859 ms)
      √ test 2: no tearing with transition (68 ms)
      × test 3: ability to interrupt render (1 ms)
      × test 4: proper branching with transition (4506 ms)
    with intensive auto increment
      √ test 5: updated properly with auto increment (2221 ms)
      × test 6: no tearing with auto increment (2 ms)

I feel like this sorta makes sense, though?  We've established the whole point of uSES is to not deal with transitions
But, I am surprised that there still appears to be tearing of some kind.

Failing test 1 is unexpected. There can be a problem somewhere, and it can be the tool.
The goal for r-r-v8 is to pass test 1, 2, and 3. 4 is not possible. (5 and 6 don't work well now).

I feel like this sorta makes sense, though? We've established the whole point of uSES is to not deal with transitions

I didn't think so, but now unsure with the recent discussion in the WG.

@dai-shi @markerikson Do y’all have a link to the react working group discussions? Happy to read new thoughts on this stuff.

will-this-react-global-state-work-in-concurrent-rendering is a community-maintained spec, so some of the assertions it makes are based on assumptions that have recently become outdated. A big one, as @markerikson pointed out, is whether external store mutations are expected to work with startTransition. That's not the case anymore — even with useMutableSource, we never guaranteed that would work in all cases, because full support for concurrency requires maintaining multiple concurrent copies of your state. The only way to do this is with the built-in APIs: useState and useReducer. You can read more background on this decision here: https://github.com/reactwg/react-18/discussions/86
The new strategy is for store updates to always be synchronous.
That doesn't mean concurrent rendering is completely disabled — you can still pass a prop that is derived from external state to useDeferredValue. That's how you might implement a typeahead, for example: a synchronous state value that controls the text input, and a deferred value that populates the typeahead suggestions.
const syncValue = useSyncExternalStore(...);
const deferredValue = useDeferredValue(syncValue);

return (
  <>
    <Input value={syncValue} />
    <ExpensiveVisualization value={deferredValue} />
  </>
);

@dai-shi, perhaps we can work together to update the will-this-react-global-state-work-in-concurrent-rendering project to match the latest expectations?

A word of caution, though: test suites like will-this-react-global-state-work-in-concurrent-rendering can be really useful for detecting the presence of certain tearing bugs — but it can't prove the absence of any tearing bugs. It's really just not possible to exhaustively prevent concurrency issues with runtime assertions; you'd need something like Rust's ownership system and compile-time borrow checker.
Simple example: one thing that's missing from the will-this-react-global-state-work-in-concurrent-rendering test suite are tests that use progressive hydration, which is another form of concurrent rendering that is different than just time slicing. Suspense is another example, of course. We have other features like pre-rendering offscreen content that introduce even more subtle scenarios. It's just not feasible for us to expect every library maintainer (whether open or closed source) to become a concurrency expert and account for every one of React's myriad upcoming features.
So instead the message is: just useSyncExternalStore. (Or useState, useReducer, or one of the other built-in APIs.) Let React worry about ensuring the correct behavior. And if you find any bugs, file an issue and we will fix them in React itself.

(sorry for the slight off topic.)

it can't prove the absence of all tearing bugs.

Totally agreeable. It's just one limited test. Passing it doesn't guarantee anything. I got interested after I saw Flarnie Marchan's talk that tearing is not hypothetical but it happened in Facebook, and it's something users can observe.

The new strategy is for store updates to always be synchronous.

Given that CM is gone, and uSES is coming, I wonder what's left to test. But,

perhaps we can work together to update the will-this-react-global-state-work-in-concurrent-rendering project to match the latest expectations?

if there's room for trial, I'm happy to help.

That doesn't mean concurrent rendering is completely disabled — you can still pass a prop that is derived from external state to useDeferredValue.

This sounds interesting, and I'm still trying to understand it. (https://github.com/reactwg/react-18/discussions/86#discussioncomment-1322765)

Totally agreeable. It's just one limited test. Passing it doesn't guarantee anything. I got interested after I saw Flarnie Marchan's talk that tearing is not hypothetical but it happened in Facebook, and it's something users can observe.

Yeah absolutely, it's a good idea and an e2e test like you've done is the right way to go about it. Only clarifying so peopel are aware of the limits of the approach.

Given that CM is gone, and uSES is coming, I wonder what's left to test.

It could still be useful to demonstrate the difference between built-in state APIs like useState versus libraries that use external systems. Or to demonstrate common patterns with popular frameworks, like the useDeferredValue pattern I posted above.
Usually when I'm evaluating a component or library to check for concurrent compatibility, I take an adversarial approach — I open the codebase and look for things that I know won't work. Almost always, the issue is something related to reading from an external data source, which is why we're so invested in providing a first-class solution to that. But we could do something similar for libraries that request it — they ask for an audit by submitting a pull request, and the reviewer identifies areas that might need to change, and creates a test that demonstrates the problem.

Do y’all have a way to squash useSyncExternalStore() shim useLayoutEffect() warnings for SSR yet? Is the intention not to use useSyncExternalStore() in SSR?

@brainkim We'll circumvent it somehow, I'm guessing with the same canUseDOM hack everyone else uses.

The plan for server rendering is to add a getServerSnapshot third argument that is called instead of the normal getSnapshot both on the server and during hydration: https://github.com/facebook/react/pull/22347
That ensures it's compatible with incremental hydration in React 18.
The userspace shim won't be able to call getServerSnapshot during hydration because older versions of React don't expose that information, but hydration is also synchronous so it's not net worse anyway. It's just as good/bad as it already is.

The server implementation landed. Available starting with 0.0.0-experimental-79b8fc667-20210920

I've spent the last couple days resuscitating the React-Redux benchmarks repo at  .  I was just able to do a v8 alpha build from this branch, load it into the benchmarks suite, and compare vs 5.x, 6.x, and 7.x:
Results for benchmark deeptree-nested:
+-----------------------------------------
¦ Version       ¦ Avg FPS ¦ Render       ¦
¦               ¦         ¦ (Mount, Avg) ¦
+---------------+---------+--------------+
¦ 5.1.2         ¦ 42.01   ¦ 212.1, 1.0   ¦
+---------------+---------+--------------+
¦ 6.0.1         ¦ 9.77    ¦ 193.1, 9.2   ¦
+---------------+---------+--------------+
¦ 7.2.5         ¦ 43.94   ¦ 221.3, 0.6   ¦
+---------------+---------+--------------+
¦ 8.0.0-alpha.0 ¦ 43.76   ¦ 223.5, 0.7   ¦
+-----------------------------------------

Results for benchmark deeptree:
+-----------------------------------------
¦ Version       ¦ Avg FPS ¦ Render       ¦
¦               ¦         ¦ (Mount, Avg) ¦
+---------------+---------+--------------+
¦ 5.1.2         ¦ 12.66   ¦ 140.6, 0.1   ¦
+---------------+---------+--------------+
¦ 6.0.1         ¦ 7.92    ¦ 133.4, 7.2   ¦
+---------------+---------+--------------+
¦ 7.2.5         ¦ 21.44   ¦ 157.9, 1.1   ¦
+---------------+---------+--------------+
¦ 8.0.0-alpha.0 ¦ 20.88   ¦ 172.6, 1.3   ¦
+-----------------------------------------

Results for benchmark forms:
+-----------------------------------------
¦ Version       ¦ Avg FPS ¦ Render       ¦
¦               ¦         ¦ (Mount, Avg) ¦
+---------------+---------+--------------+
¦ 5.1.2         ¦ 49.67   ¦ 1371.0, 0.4  ¦
+---------------+---------+--------------+
¦ 6.0.1         ¦ 49.42   ¦ 1452.5, 3.0  ¦
+---------------+---------+--------------+
¦ 7.2.5         ¦ 49.69   ¦ 1321.1, 0.4  ¦
+---------------+---------+--------------+
¦ 8.0.0-alpha.0 ¦ 47.06   ¦ 1331.3, 0.5  ¦
+-----------------------------------------

Results for benchmark stock-ticker:
+-----------------------------------------
¦ Version       ¦ Avg FPS ¦ Render       ¦
¦               ¦         ¦ (Mount, Avg) ¦
+---------------+---------+--------------+
¦ 5.1.2         ¦ 33.08   ¦ 424.5, 0.9   ¦
+---------------+---------+--------------+
¦ 6.0.1         ¦ 12.86   ¦ 331.3, 11.8  ¦
+---------------+---------+--------------+
¦ 7.2.5         ¦ 32.82   ¦ 469.7, 0.6   ¦
+---------------+---------+--------------+
¦ 8.0.0-alpha.0 ¦ 29.69   ¦ 463.0, 0.6   ¦
+-----------------------------------------

Results for benchmark tree-view:
+-----------------------------------------
¦ Version       ¦ Avg FPS ¦ Render       ¦
¦               ¦         ¦ (Mount, Avg) ¦
+---------------+---------+--------------+
¦ 5.1.2         ¦ 40.12   ¦ 866.8, 0.3   ¦
+---------------+---------+--------------+
¦ 6.0.1         ¦ 28.95   ¦ 741.3, 27.2  ¦
+---------------+---------+--------------+
¦ 7.2.5         ¦ 43.40   ¦ 896.8, 0.3   ¦
+---------------+---------+--------------+
¦ 8.0.0-alpha.0 ¦ 44.37   ¦ 1020.8, 0.3  ¦
+-----------------------------------------

Results for benchmark twitter-lite:
+-----------------------------------------
¦ Version       ¦ Avg FPS ¦ Render       ¦
¦               ¦         ¦ (Mount, Avg) ¦
+---------------+---------+--------------+
¦ 5.1.2         ¦ 23.57   ¦ 110.4, 2.0   ¦
+---------------+---------+--------------+
¦ 6.0.1         ¦ 13.81   ¦ 109.4, 10.8  ¦
+---------------+---------+--------------+
¦ 7.2.5         ¦ 23.90   ¦ 125.4, 1.1   ¦
+---------------+---------+--------------+
¦ 8.0.0-alpha.0 ¦ 23.32   ¦ 136.0, 1.1   ¦
+-----------------------------------------

Those numbers come with a bunch of caveats:

FPS is a lousy metric, but it's a number
These are horribly synthetic benchmarks (as in, "Mark cranked up the NUM_COMPONENTS constant until the numbers dropped below 60FPS")
This is only for connect. I haven't set up any scenarios with useSelector yet, although I should be able to do that now that I've revamped the build setup
What really matters here is the relative FPS values, and the "mount/render" numbers
This is just one run, and the numbers do fluctuate a bit from run to run

Overall, the key takeaway is that connect on this branch is basically equivalent in perf to connect in v7, which is exactly what I would hope and expect given the actual changes I made so far, and that there's no major regressions like we had in v6.
I'll look at trying to set up some useSelector benchmarks soon.

I spent the evening trying to get a hooks-based benchmarks scenario in place. I did. And then the first time I ran it with 8.0-alpha, the app never updated.
Know why?
BECAUSE ANDREW CHANGED THE ORDER OF THE ARGUMENTS TO useSyncExternalStore AND THE EQUALITY FUNCTION WAS GETTING TREATED AS getSnapshot! :)
The latest alpha had gotten installed in the benchmarks repo, but I hadn't tried to update React-Redux to match that yet. Oops.
So, for now I just stubbed out getServerSnapshot to reuse store.getState. YES, I KNOW THIS IS "WRONG".  I just wanted to keep the client-side code running for now so I could benchmark things.
First meaningful hooks scenario results:
Results for benchmark deeptree-nested-hooks:
+-----------------------------------------
¦ Version       ¦ Avg FPS ¦ Render       ¦
¦               ¦         ¦ (Mount, Avg) ¦
+---------------+---------+--------------+
¦ 7.2.5         ¦ 44.33   ¦ 167.5, 0.5   ¦
+---------------+---------+--------------+
¦ 8.0.0-alpha.0 ¦ 45.75   ¦ 166.4, 0.6   ¦
+-----------------------------------------

Again, the numbers are very imperfect and this is just one benchmark, but traditionally this is the one that's shown the biggest variation between different builds.  So, very encouraging that 7.x and 8.x are basically identical here.
Also... ALL THE TESTS NOW PASS!  Like I said, I know the SSR behavior is wrong and I'll have to sort out what to do with that.
Andrew has suggested having some kind of a serverSnapshot prop in Provider itself, which I guess would require passing that down via context and having a trivial () => serverSnapshot getter in use everywhere in the tree if that's available.  On my todo list, but I'll need some time to let that sink in.

I just ripped the Subscription usage out of useSelector.  All tests still pass, except the one we had that specifically checked for "you can stick a connect()ed component above and it will subscribe to that instead" (ie, the use case I mentioned above).
I also realized the TS types output was getting nested one level too deep (as ./es/src/index.d.ts instead of ./es/index.d.ts), which made the published package busted for TS usage.  Managed to fiddle with the tsconfig enough to make that seem to cooperate and the types work right now.

I rebased this against master, and squashed a bunch of temp commits together to clean up the history.  I also fixed up some types issues.  Tests pass, types pass, the CSB build looks like it runs and compiles okay in an example app.  I think it's time to merge this PR and publish an initial v8 alpha so that people could start trying it out.
I still haven't tried to implement an actual API for server snapshots. I'll tackle the SSR thing in a follow-up.
I've updated the React peerDep to list 16 || 17 || 18 (although I don't know how to list "experimental" builds here). Per prior comments, I'm generally planning to make this 18-only by the time it's out.
Related to that, I'm seriously considering removing the use-sync-external-store shim dep, and inlining the logic from useSyncExternalStoreExtra back into useSelector.  Otherwise, the logic from the useSyncExternalStore shim function ends up in the final app bundle even when you're using the built-in uSES function, and that's just a waste of bytes.  If we're not going to support 16/17 via the shim in the final v8 release, then I don't see a point in having that dep at all.
Also, I had removed use of Subscription from useSelector, but that still ends up in the app bundle because Provider has to use it in case there's some connect usage in the app.  So, can't get away from that.

@markerikson We could publish a version of the "extra" module that relies directly on the native API, instead of using the shim indirection. That way if multiple libraries depend on it, users only download the code once.

@acdlite yup, that'd definitely be another possibility, and I'd be good with that.

Also FYI to anyone reading, these changes are now live in https://github.com/reduxjs/react-redux/releases/tag/v8.0.0-alpha.0 !

If we're not going to support 16/17 via the shim in the final v8 release, then I don't see a point in having that dep at all.

My understanding is that the shim will support post-hooks versions once the API is stable.

My point is that the "shim" part is only useful if we planned to have v8 be compatible with 16/17.  But, I was already planning to enforce a hard switch so that React-Redux v8 requires React 18, in the same way that React-Redux v7 required 16.8+ for hooks support.
As currently written, the use-sync-external-store package will always end up including the shim code itself in the final app bundle, even if you're using a version of React that does have a real uSES.  If we really do hard-require React 18, then that's a useless 750 bytes for end users that wouldn't even run.

As of https://github.com/facebook/react/pull/22662, if you import use-sync-external-store/with-selector it will compose the built-in React API, not the shim. (The shim version is available as a separate import: use-sync-external-store/shim/with-selector.)

Also, I had removed use of Subscription from useSelector

Hello, shouldn't this bring back the old quadratic algorithm and slow unmount of many components (#1523)?
Since Redux unsubscribe is passed to useSyncExternalStore and it relies on indexOf\splice (like in version <7.2.0)
Thank you

@kasdy : not sure, but if there's a problem here it's probably going to be a React issue rather than a React-Redux issue specifically.
Could you try to set up a test case with both React-Redux v8 + React 18, but also "just" React 18 + a fake little store implementation + useSyncExternalStore, and see what the actual behavior looks like?

@markerikson

Hmm. However... because we're now using store.subscribe directly, that does use indexOf/splice.

Yes! that's what I meant :)
I adapted the benchmark code in #1523 to use Hooks and tested:
React 17 + React-Redux v7.2.6

React 18 + React-Redux v8.0.0

const store = createStore(
    (state = 0, action) => (action.type === "INC" ? state + 1 : state)
);
const increment = () => ({ type: "INC" });

function App() {
    const state = useSelector(s => s);
    const dispatch = useDispatch();

    const [children, setChildren] = useState(0);

    const toggleChildren = () => setChildren(c => c ? 0 : 50000);

    return <div>
        <button onClick={toggleChildren}>Toggle Children</button>
        <button onClick={() => dispatch(increment())}>Increment</button>
        {[...Array(children).keys()].map(i => <Child key={i}/>)}
    </div>;

}

function Child() {
    const v = useSelector(s => s);
    return <div className="child">{v}</div>;
}

Gotcha.
Could you file a new issue so we can keep track of this separately?
Also: I would really like to have a unit test that captures this intended behavior so that we don't regress again, but off the top of my head I don't know how you'd actually validate this experimentally (especially since perf-sensitive behavior is not a good fit for unit tests that run in C).

@markerikson
done #1869
About the unit test, that would be really cool, but I can't think of a way to detect it... because it works even though it's slow.
measuring the test execution time does not look good to me either.
I discovered it by chance, because I was studying the new React18 hooks, and I was digging in React-Redux source.

Also also: if you have time to file a PR that changes useSelector back to using Subscription again, that would be great!

I have to check the guidelines and everything... but I think I can do it :) it will be my first PR, it will be fun :D

authors: Kasdy acdlite brainkim dai-shi eps1lon markerikson timdorr

repo: reduxjs/react-redux


text:
Swap useSyncExternalStore shim behavior and update React deps

This PR:

Updates all React-related dependencies to React 18 final
Updates React Testing Library
Swaps the shim behavior so that the primary entry point now uses the useSyncExternalStore shim behavior as the default
Changes the old "/compat" entry point so that it is now "/next" and imports uSES directly from React without using the shim
Updates the Jest test setup to test all three scenarios (main entry + React 18, main entry + React 17, next entry + React 18)
Adds TS 4.6 to the TS test matrix

Just did a quick bundle size comparison of React-Redux 7.2.8, 8.0-beta.3 (with no uSES shim), and a build from this branch (with uSES shim).  The setup is a Vite app with React 18 and RTK 1.8.1, and a store with a basic counter slice and <Counter> component.
As best as I can tell from source-map-explorer, the vendor chunk sizes (including all of React, ReactDOM, RTK, and Immer) are:

7.2.8: 167.33K
8.0-b3: 167.21K
8.0-b4: 167.99K

In other words:

8.0-b3 is 120b smaller than 7.x, minified
8.0-b4 is 600b larger than 7.x, minified

But, that 600 bytes gets us compat with React 16.8/17, and makes it possible for people to easily upgrade to React-Redux v8 even if they aren't using React 18 yet.  It also ensures compat with React Native, which won't support React 18 until the "New Architecture" is fully released:
https://reactnative.dev/blog/2022/03/30/version-068#opting-in-to-the-new-architecture
So, that slight increase in bundle size is well worth it.
Also, users who are on React 18 can alias the "/next" entry point and drop the shim from their bundle.

source: gharchive/pull-request

license: MIT

license_type: permissive

license_source: github-api


text:
crossSliceReducer example is buggy-maybe

What docs page needs to be fixed?
https://redux.js.org/recipes/structuring-reducers/beyond-combinereducers

Section:  recipes
Page: structuring-reducers/beyond-combinereducers

What is the problem?
I believe the example of the third approach with the crossSliceReducer has a bug.
The sliceReducerB will be executed twice.
Here is the example from the doc with an added inline comment pointing the problem.
const combinedReducer = combineReducers({
  a: sliceReducerA,
  b: sliceReducerB
})

function crossSliceReducer(state, action) {
  switch (action.type) {
    case 'SOME_SPECIAL_ACTION': {
      return {
        // specifically pass state.b as an additional argument
        a: handleSpecialCaseForA(state.a, action, state.b),
        b: sliceReducerB(state.b, action)  //  ⚠🐛 state.b has already been updated by sliceReducerB in the combined reducer.
      }
    }
    default:
      return state
  }
}

function rootReducer(state, action) {
  const intermediateState = combinedReducer(state, action)
  const finalState = crossSliceReducer(intermediateState, action)
  return finalState
}

If we take the following simple reducer
function sliceReducerB(stateB = {counter: 0}, _action) {
 return {counter: counter+1}
}

We will have the following state (only showing slice B) :
function rootReducer(state, action) {
  const intermediateState = combinedReducer(state, action)
  // intermediateState is {b: counter: 1,  }
  const finalState = crossSliceReducer(intermediateState, action)
  // finalState is {b: counter: 2} 😿
  return finalState
}

What should be changed to fix the problem?
The crossSliceReducer should only update a.

Appreciate the concern, but this is mostly intentional.
A couple things here:

First, it's a made-up example. The actual reducer logic could be anything we want it to be.
Second, in this specific example, the assumption is that sliceReducerB probably knows nothing about SOME_SPECIAL_ACTION - this crossSliceReducer is most likely the only function that actually cares about that.  So, if that action is dispatched, slice B probably won't have updated because it doesn't care about this action.

Given all that, I'm inclined to leave the example as-is.
Please let us know if you do have any other questions or concerns about the docs examples!

Thank you for clarifying the intention of the example.

source: gharchive/issue

authors: lazybean markerikson

repo: reduxjs/redux


text:
feat(server): integration usecase

Overview
What I've done
What I haven't done
How I tested
Screenshot
Which point I want you to review particularly
Memo

Closed by #240

repo: reearth/reearth-cms


text:
[BE]Return an error when a new project was about to be created by a reader

App should return an error when a new project was about to be created by a reader.

We have an error here already. We also need to support showing more details in the future.

authors: HideBa lavalse

repo: reearth/reearth-visualizer


text:
What is skipD in main_cls.lua and main_cls_int.lua?

Hi Reed,
In your code, there is "skipD", what does this mean? Is it a typo? (maybe conv is right) Thanks.
    -- state size: (ndf*8) x 4 x 4     local conc = nn.ConcatTable()     local conv = nn.Sequential()     conv:add(SpatialConvolution(ndf * 8, ndf * 2, 1, 1, 1, 1, 0, 0))     conv:add(SpatialBatchNormalization(ndf * 2)):add(nn.LeakyReLU(0.2, true))     conv:add(SpatialConvolution(ndf * 2, ndf * 2, 3, 3, 1, 1, 1, 1))     conv:add(SpatialBatchNormalization(ndf * 2))     conv:add(nn.LeakyReLU(0.2, true))     conv:add(SpatialConvolution(ndf * 2, ndf * 8, 3, 3, 1, 1, 1, 1))     conv:add(SpatialBatchNormalization(ndf * 8))     conc:add(nn.Identity())     conc:add(skipD)     convD:add(conc)     convD:add(nn.CAddTable())

Hi,
I have the same question. Were you able to figure out what it was?
Thanks!

license: mit

license_source: bigquery


text:
Development

Description
GitHub Issues

Coverage remained the same at 92.201% when pulling fec2739df0da7f0ba9c14da16623143c866b5e72 on development into d4a669e543b3d09a8c23d9d00d4601e8bff64724 on master.

Coverage remained the same at 92.201% when pulling fec2739df0da7f0ba9c14da16623143c866b5e72 on development into d4a669e543b3d09a8c23d9d00d4601e8bff64724 on master.

authors: coveralls mcrowson

repo: refindlyllc/rets


text:
Hide sponsor items in hide-noisy-newsfeed-events

Description
They are similar to follow items which we already hide.
Sponsor items have .sponsor classes on them.
Screenshot

Example URL
https://github.com/

I was thinking the same when I saw #5018, but sponsorship events are a positive thing in the community so I'd like to keep them visible

authors: fregante kidonng

repo: refined-github/refined-github


text:
hide-newsfeed-noise isn't hiding grouped "follow" events correctly

Description

How to replicate the issue + URL
https://github.com/
Extension version
23.2.5
Browser(s) used
Chrome

🤔 we dropped that feature 2 versions ago. Can you close and reopen your browser?
If it's still there, can you look at the DOM of the page to see what selector is hiding those elements?

Duplicate of https://github.com/refined-github/refined-github/issues/6232

Fixed in #6306 and via hotfix 👍

@fregante
This time doesn't work for fork


text:
Update scala-library to 2.12.15

Updates org.scala-lang:scala-library from 2.12.11 to 2.12.15.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (2.12.11).
You might want to review and update them manually.
build.sbt

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang", artifactId = "scala-library" } ]

labels: library-update, semver-patch, old-version-remains

Superseded by #146.

Superseded by #149.

repo: regadas/scio-contextual


text:
fixed label mapping mistakes

Description
This PR fixes mistakes in label mapping for synthseg tissue segmentation.

please run integration

repo: reghbali/pyalfe


text:
add support of arraybuffer in regl.buffer()

This PR includes a new feature and a fix:

Feature
Be able to use arraybuffer directly in regl.buffer()

const arrBuf = new ArrayBuffer(1024);
const buffer = regl.buffer(arrBuf);

Fix
Fixed missing glTypes constant when building attributes snippets.

LGTM!

authors: dy fuzhenn

repo: regl-project/regl


text:
Resize canvas using ResizeObserver if available

Use ResizeObserver when available to detect changes in canvas container size, except if rendering full screen (to body).

@dy @mikolalysenko Just in case anyone else has feedback, feel free to respond, otherwise I'll try to release this (a minor version bump, I think, in case the addition of this feature would conceivably cause unexpected issues?) soon, hopefully this afternoon.

I'm getting a single test failure but it doesn't appear new and I'm unable to debug at the moment, so I think I'm going to just go ahead with publishing:
https://github.com/regl-project/regl/blob/cadd226650d345ac3599b067ebfb848439dc4fd8/test/dynamic-elements.js#L60-L73
not ok 4389 line and point
  ---
    operator: deepEqual
    expected: |-
      [ 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1 ]
    actual: |-
      [ 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0 ]
    stack: |-
      Error: line and point
          at Test.assert [as _assert] (http://192.168.1.126:9968/browser.js:23811:54)
          at Test.bound [as _assert] (http://192.168.1.126:9968/browser.js:23663:32)
          at Test.tapeDeepEqual (http://192.168.1.126:9968/browser.js:24009:10)
          at Test.bound [as same] (http://192.168.1.126:9968/browser.js:23663:32)
          at checkPixmap (http://192.168.1.126:9968/browser.js:28502:7)
          at Test.<anonymous> (http://192.168.1.126:9968/browser.js:28516:3)
          at Test.bound [as _cb] (http://192.168.1.126:9968/browser.js:23663:32)
          at Test.run (http://192.168.1.126:9968/browser.js:23679:10)
          at Test.bound [as run] (http://192.168.1.126:9968/browser.js:23663:32)
          at next (http://192.168.1.126:9968/browser.js:23447:19)

authors: deluksic rreusser


text:
JPEG files do not save in the correct orientation

Currently, after taking an image to be saved as JPEG, the image viewer displays it correctly oriented, but upon saving, the image is always landscape.

Do you save with EXIF-data included? You might look into that, especially the orientation tag. See: https://exiftool.org/TagNames/EXIF.html 🤔

@Ytrog Thank you for the suggestion! I just added #9 to address this.

@Ytrog Thank you for the suggestion! I just added #9 to address this.

Glad I could help ☺

authors: Ytrog reilandeubank

repo: reilandeubank/unprocess


text:
🛑 SmartProtection is down

In 13e28c6, SmartProtection (https://smartprotection.com) was down:

HTTP code: 404
Response time: 1102 ms

Resolved: SmartProtection is back up in 67fd60c after 1 hour, 19 minutes.

repo: reinaldoleon/monitoring


text:
🛑 BINUSMAYA (Academic Services) is down

In ab83168, BINUSMAYA (Academic Services) (https://binusmaya.binus.ac.id/LoginAD.php) was down:

HTTP code: 404
Response time: 859 ms

Resolved: BINUSMAYA (Academic Services) is back up in 0ff4b0a.


text:
🛑 BISANARA is down

In 6c8c865, BISANARA (https://bisanara.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: BISANARA is back up in 0c22007.


text:
🛑 BINUS ISRA API Server 1 is down

In 1c3b2de, BINUS ISRA API Server 1 (https://qmc.apps.binus.ac.id/api/v1/loadSetting) was down:

HTTP code: 0
Response time: 0 ms

Resolved: BINUS ISRA API Server 1 is back up in 7a6d7bb.


text:
🛑 GreatNusa.com is down

In 790ae6c, GreatNusa.com (https://greatnusa.com) was down:

HTTP code: 403
Response time: 82 ms

Resolved: GreatNusa.com is back up in 60888be.


text:
🛑 GreatNusa.com is down

In 45f792f, GreatNusa.com (https://greatnusa.com) was down:

HTTP code: 403
Response time: 156 ms

Resolved: GreatNusa.com is back up in 21a5cf9.


text:
🛑 GreatNusa.com is down

In ca0f9b0, GreatNusa.com (https://greatnusa.com) was down:

HTTP code: 403
Response time: 113 ms

Resolved: GreatNusa.com is back up in 89672f6.


text:
🛑 GreatNusa.com is down

In f894112, GreatNusa.com (https://greatnusa.com) was down:

HTTP code: 403
Response time: 82 ms

Resolved: GreatNusa.com is back up in d2ad769.


text:
Add rawResume

The HTTP/2 driver manages stream lifetime similar to a TCP connection. I have a read/write event loop and tasks opened for every subsequent inter-connection streams. When these tasks need to write through the HTTP/2 protocol, they might yield just like within the TCP Connection.
See here to see how the task is stopped:
https://github.com/etcimon/vibe.d/blob/c064f3bafc43ea824206d2ecbe2eba4ea0163012/source/vibe/http/http2.d#L250
And how the task is resumed once the buffers are flushed:
https://github.com/etcimon/vibe.d/blob/c064f3bafc43ea824206d2ecbe2eba4ea0163012/source/vibe/http/http2.d#L88
I want the read/write loops to leave those tasks untouched, but I don't want to acquire locks in the process of context switching because those are guaranteed to be single-threaded operations.
For this reason, I'd like to add the rawResume feature which schedules the stream resumption before the event loop blocks in the OS.

The usual primitives for these kinds of tasks are TaskMutex, TaskCondition, ManualEvent, or vibe.core.concurrency.send. TaskPipe may also be a possibility. But generally, rawYield and resumeTask should never appear outside of the event driver and the driver code code.

Edit: replied a bit too fast, w.r.t locks. But still this is something that should be done using a higher level primitive.

It seems a little wrong to use a high-level primitive for this purpose, because these HTTP2Streams are essentially the same as a TCPConnection. Considering the slow process in sending a notification through the OS event loop, I don't really think ManualEvent is the right way to go.
I'm essentially trying to achieve a ThreadLocalManualEvent like we talked earlier, but I'm not sure how you would implement that.

BUt this reminds me that ManualEvent should have an optimization to not use the event loop at all if the respective tasks are in the same thread, but use DriverCode.yieldAndResumeTask instead (in .emit()).

but use DriverCode.yieldAndResumeTask instead (in .emit()).

I can't find this function, did you write an implementation for it or is it an idea at the moment?
I would implement it by pushing the ManualEvent waiter in vibe.core.core.s_yieldedTasks and then calling vibe.core.core.yield(), is this right?

Yes, that's about it. It's currently still in a branch, because I want to defer the related changes to the next release: https://github.com/rejectedsoftware/vibe.d/blob/466751cd581bdef90e9fcbf97a580e2d495152a5/source/vibe/core/core.d#L1083

Ok, seems the same as rawResume except that you're forcing emit() to yield the task. Wouldn't that count as an unexpected side effect?
Also, it seems that HTTP/2 and Botan TLS could provide their own buffer to TCPConnection. I'm thinking of making the TCPConnection buffer initialize lazily in libasync driver, so that read(ubyte[] dst) used with a dst.length >= WindowSize can set the buffer in the object for the kernel to write to while the task is waiting. If this buffer goes over capacity, it would fall back on initializing the circular buffer.
Also, I would need a setWindowSize/getWindowSize in the TCPConnection because HTTP/2 has its own flow control implementation. You think it would be a good addition?

Also, I don't think the presence of high-level primitive should restrict users from using low-level "Hacks" in an effort of optimizing its code. It's like inline assembly, it should be there even for the slight chances that it could improve the program when properly used.

The idea for vibe.d is to present an interface to the library user, where all the details of the underlying I/O and threading model are abstracted away. It should, for example still be possible to replace fibers by threads and synchronous I/O with synchronous I/O without breaking any user code. This could be important for certain platforms or in certain library environments.
Anything that semantically relies on the fiber model is thus nothing for the public API. rawYield is an exception that was necessary for some hacks in the past, but I'd even go as far to remove that function before 1.0.0. Basing such kinds of inter-task control on more generic primitives makes the code more general and more robust.
The only reason that I can see to not do this would be performance issues, but those can be resolved. Using yieldAndResume in emit() would be absolutely OK from a semantic perspective, but you are right that it may in certain cases not be the intended behavior from a performance point of view, and something that doesn't yield, like your rawResume, might be more appropriate. However, such a function should be part of DriverCore and not part of the user facing API. Maybe like the following:

DriverCore.resumeTask - directly resumes the task, can only be called by the event loop
DriverCore.yieldAndResumeTask - directly resumes the task and in turn yields the current one
DriverCore.scheduleResumeTask - schedules the task for resumption, but continues the current one

or possibly using a control enum instead:
DriverCore.resumeTask(Task task, Exception exception = null, TaskResumeMode mode = TaskResumeMode.immediate);
enum TaskResumeMode {
    immediate,
    yield,
    schedule
}

The new resumeTask would seem good for any other kind of user protocol. However, HTTP/2 is currently the most important solution towards scaling up as much as possible on web servers. A decent implementation would have to make the HTTP/2 backend lock-less, and the mutex would definitely make a difference in benchmarks. We could add it to the core and allow it to access the DriverCore by annotating the accessor with a package visibility? I'd need it to provide its own buffer as well to TCPConnection, to save a 64kb per connection.

If you directly use ManualEvent instead of a task mutex/condition and ManualEvent uses scheduleResumeTask instead of pushing an event to the event loop, there should be no difference in performance, AFAICS. BTW, what do you mean by making the HTTP/2 backend lock-less? You have to implement some kind of wait operation, which could easily qualify as a kind of lock. However, vibe.d is always lock-less in the classical thread based sense. TaskMutex only uses a CAS operation to be thread-safe.
Making the TCP receive window size configurable would be good to have. But is there a reason why you can't use the buffer that is already provided to TCPConnection.read (i.e. what kind of API change do you need)?

However, vibe.d is always lock-less in the classical thread based sense. TaskMutex only uses a CAS operation to be thread-safe.

I think it's worth a try. I was mostly concerned about this: https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/drivers/libasync.d#L760

But is there a reason why you can't use the buffer that is already provided to TCPConnection.read (i.e. what kind of API change do you need)?

I only need a void read(ubyte[] dst, ref int len), which yields like leastSize but also asks the event loop to fill the dst before resuming. The task will either yield here or in the HTTP/2 event loop, because there's a "pause" feature that blocks the connection (which is why ref int is used). However, the buffer should never be exceeded because the protocol has a flow control, there are WINDOW_UPDATE frames sent to the remote peer to indicate how much of the buffer was read and trigger more data be sent.
The reason I need this is because it's possible to make a save here, the reader task will have to create its own buffer anyways with the exact window size and has nothing else to wait for. Might as well make the kernel write to it directly. I'll make the same optimization in the TLS library, and with the growing buffer I can guarantee a minimal size of 2kb buffer per connection which grows up to windows_size.

Making the TCP receive window size configurable would be good to have

Good, I'll add that, it will allow the flow control to work better (the WINDOW_UPDATE frame works on connection and on stream levels)

Closed because I opened a new one more relevant

authors: etcimon s-ludwig


text:
Hide expand on list UI

Made new adapter ListAdapterHideExpand
It implements hide and expand. Items are structured in different levels.
It takes a normal list of strings but the levels are being based on the string-name if and how many '>' it starts with
colors are a bit better
ListUI changes
I had to implement a scroll bar updater because now we have a list that can change is length

NOTE: it is not done but I think we should merge with dev just so are sure that nothing have been broken on the normal ListUI

repo: remance/Masendor


text:
feat: add subscription status get

What is the motivation for this pull request?
feat: add subscription status get
https://www.braze.com/docs/api/endpoints/subscription_groups/get_list_user_subscription_group_status/
What is the current behavior?
No method to get the subscription state of a user in a subscription group
What is the new behavior?
Method to get the subscription state of a user in a subscription group: braze.subscription.status.get()
Checklist:

[x] Conventional Commits
[x] Tests
[x] Documentation

Codecov Report

Merging #55 (558bb68) into master (ef51650) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #55   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           54        55    +1
  Lines          253       267   +14
  Branches         5         8    +3
=========================================
+ Hits           253       267   +14

Impacted Files
Coverage Δ

src/Braze.ts
100.00% <100.00%> (ø)

src/subscription/status/get.ts
100.00% <100.00%> (ø)

src/subscription/status/index.ts
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

authors: codecov-commenter remarkablemark

repo: remarkablemark/braze-api


text:
feature: different travel color to distinguish air-cutting and actual-cutting in CNC

different travel color to distinguish air-cutting and actual-cutting in CNC.

Hello @xuzhen1994 ! Thanks for your PR! 😄
It's great to have better support for CNC!
However, defining travel at z <= 0 as cutting is not true in general. Sometimes the z = 0 is defined at the bottom of the stock, sometimes at the top. And for 3d milling cutting/not-cutting is totally different story.
Have you looked at the nonTravelMoves option? It would depend on your gcode.
Otherwise, maybe you can create a function parameter so that you can pass the logic that works for your case:
const preview = GCodePreview.init({
      canvas: document.querySelector('canvas'),
      travelColor: (start, end) => start.z > 0 ||  end.z > 0 ? 'green' : 'red'
});

Here start and end would be the states (x,y,z etc) at the start and end of the line segment.

Also, could you share a gcode snippet for your case please?

@remcoder Thanks for your suggestion! I have added the isActualCutting option to support users in customizing the logic for actual-cutting. In addition to color differentiation, I have also added statistics for the actual-cutting distance and air-cutting distance. I would like to calculate the cutting duration as well, but currently the gcode parser cannot parse the F parameter and the S parameter. I will work on improving this functionality when I have time in the future. Also, this is my first time using the TypeScript language, so please let me know if there are any issues. Thanks again!

my gcode
T1
G43 H1
M03 S18000
G00 X176.604 Y554.890
G00 Z10.000
F4000
G01 Z-12.100
F12000
G02 X183.675 Y561.961 I3.536 J3.536
G02 X176.604 Y554.890 I-3.536 J-3.536
F4000
G00 Z20.000
G00 X-4.000 Y785.175
G00 Z10.000
G01 Z-12.100
F12000
G02 X-0.000 Y789.175 I4.000 J0.000
G01 X380.139 Y789.175
G02 X384.139 Y785.175 I0.000 J-4.000
G01 X384.139 Y331.675
G02 X380.139 Y327.675 I-4.000 J0.000
F4000
G00 Z20.000
G00 X457.500 Y323.675
G00 Z10.000
G01 Z-12.100
F12000
G02 X461.500 Y327.675 I4.000 J0.000
G01 X915.000 Y327.675
G02 X919.000 Y323.675 I-0.000 J-4.000
F4000
G00 Z20.000
G00 X457.500 Y256.000
G00 Z10.000
G01 Z-12.100
F12000
G03 X453.500 Y260.000 I-4.000 J0.000
F4000
G00 Z20.000
G00 X457.500 Y176.000
G00 Z10.000
G01 Z-12.100
F12000
G03 X461.500 Y172.000 I4.000 J0.000
F4000
G00 Z20.000
G00 X457.500 Y168.000
G00 Z10.000
G01 Z-12.100
F12000
G03 X453.500 Y172.000 I-4.000 J0.000
F4000
G00 Z20.000
G00 X457.500 Y88.000
G00 Z10.000
G01 Z-12.100
F12000
G03 X461.500 Y84.000 I4.000 J0.000
F4000
G00 Z20.000
G00 X457.500 Y80.000
G00 Z10.000
G01 Z-12.100
F12000
G03 X453.500 Y84.000 I-4.000 J0.000
F4000
G00 Z20.000
G00 X457.500 Y0.000
G00 Z10.000
G01 Z-12.100
F12000
G02 X453.500 Y-4.000 I-4.000 J0.000
F4000
G00 Z20.000
G00 X461.500 Y-4.000
G00 Z10.000
G01 Z-12.100
F12000
G02 X457.500 Y-0.000 I-0.000 J4.000
G01 X457.500 Y80.000
G02 X461.500 Y84.000 I4.000 J0.000
G01 X915.000 Y84.000
G03 X919.000 Y88.000 I0.000 J4.000
F4000
G00 Z20.000
G00 X915.000 Y84.000
G00 Z10.000
G01 Z-12.100
F12000
G02 X919.000 Y80.000 I-0.000 J-4.000
F4000
G00 Z20.000
G00 X915.000 Y172.000
G00 Z10.000
G01 Z-12.100
F12000
G03 X919.000 Y176.000 I-0.000 J4.000
F4000
G00 Z20.000
G00 X919.000 Y256.000
G00 Z10.000
G01 Z-12.100
F12000
G03 X915.000 Y260.000 I-4.000 J0.000
F4000
G00 Z20.000
G00 X919.000 Y264.000
G00 Z10.000
G01 Z-12.100
F12000
G02 X915.000 Y260.000 I-4.000 J0.000
G01 X461.500 Y260.000
G03 X457.500 Y256.000 I-0.000 J-4.000
G01 X457.500 Y176.000
G02 X453.500 Y172.000 I-4.000 J0.000
G01 X0.000 Y172.000
G03 X-4.000 Y168.000 I-0.000 J-4.000
F4000
G00 Z20.000
G00 X0.000 Y172.000
G00 Z10.000
G01 Z-12.100
F12000
G02 X-4.000 Y176.000 I-0.000 J4.000
F4000
G00 Z20.000
G00 X-0.000 Y260.000
G00 Z10.000
G01 Z-12.100
F12000
G02 X-4.000 Y264.000 I0.000 J4.000
F4000
G00 Z20.000
G00 X-4.000 Y323.675
G00 Z10.000
G01 Z-12.100
F12000
G02 X-0.000 Y327.675 I4.000 J0.000
F4000
G00 Z20.000
G00 X-4.000 Y331.675
G00 Z10.000
G01 Z-12.100
F12000
G03 X0.000 Y327.675 I4.000 J0.000
G01 X453.500 Y327.675
G02 X457.500 Y323.675 I0.000 J-4.000
G01 X457.500 Y264.000
G02 X453.500 Y260.000 I-4.000 J0.000
G01 X-0.000 Y260.000
G03 X-4.000 Y256.000 I0.000 J-4.000
F4000
G00 Z20.000
G00 X-4.000 Y88.000
G00 Z10.000
G01 Z-12.100
F12000
G03 X-0.000 Y84.000 I4.000 J0.000
F4000
G00 Z20.000
G00 X-4.000 Y80.000
G00 Z10.000
G01 Z-12.100
F12000
G02 X-0.000 Y84.000 I4.000 J0.000
G01 X453.500 Y84.000
G03 X457.500 Y88.000 I0.000 J4.000
G01 X457.500 Y168.000
G02 X461.500 Y172.000 I4.000 J0.000
G01 X915.000 Y172.000
G02 X919.000 Y168.000 I0.000 J-4.000
F4000
G00 Z20.000
G00 X461.500 Y260.000
G00 Z10.000
G01 Z-12.100
F12000
G02 X457.500 Y264.000 I0.000 J4.000
F4000
G00 Z20.000
M05
M17
M30

Hi again! Thanks for the improvements.
The library is for 3d printing too where 'cutting' doesn't exist. That's why I suggested passing in an option for the color, making it generic.
But my suggestion will not work if you want to track the total cutting distance.
I think that for both the  (non)-cutting color and distance I'm looking for a solution that isn't specific to cnc. At least the default will need to work where cutting doesn't work or is defined differently.
Let us know if you can work it out. Also feel free to join the discord to discuss this 🙂

hi @xuzhen1994!
Nice proposal but we need to keep the library working for other (non-cnc) usecases too.
For the color changing (z <= 0) I want to remind you of my proposal to define a function that will decide on the travel color using arbitrary logic. That would be a simple generic solution that I can merge.
Furthermore, keeping the stats for cutting don't belong in the webglpreview class. (in fact the class already does too much so we're discussing on discord how to split it up)
The best way would be to move the cutting stats to the parser:

create a variant (subclass?) of the parser that tracks the cutting.
add the stats to the layer object

Let's do the color change in 1 PR and the stats in another PR. That keeps it simple and moving.

@xuzhen1994 I have to apologize. My proposal isn't as easy as I thought.. The reason is that the library groups lines into layers because that's useful for 3d printing. Lines within a layer a rendered in a single go and all consecutive travel lines will share a single color.
To enable different travel colors, the lines will need to be ungrouped (or not grouped to begin with).
I would like to help out with getting this solved. I cannot push to your fork however. Would you be ok with allowing me to do so?

Thanks for the advice. Apologies, due to work and effort, I can't promise to finish your proposal by a certain time. I have invited you as collaborator, and let me know if you need anything else.

@xuzhen1994 I added some commits and you can see the different travel colors working. Still very hacky and not mergable. I'll clean it up later to get it mergable but then I have to leave out the statistics part (for reasons mentioned above).

btw, I already have push access to your branch so I don't need to be added to the repo. I'll decline that invite because it is not needed, thanks anyway.

I just realized that there could be a 'cnc mode'. We're probably introducing modes for different views and a cnc mode could fit into that scheme. Let's wait far those modes to land first.

repo: remcoder/gcode-preview


text:
_initWithId(id: Int) returns data, with some offset

I have a model name Ingredient having name, brand, cost
When I _initWithId some ingredient the object that I get is of type "Ingredient" but it's properties are not returned in the correct way. i.e. when I access .name it returns empty, but when access .brand it returns the name and on .cost it returns the brand.. simple it does the following
.name = ""
.brand = .name
.cost = .brand
.cost = (Only God knows)
Does anybody understand this error? Can anyone please help me with it, I have tried to make a breakpoint in CamembertModel.swift and try to track down the error but no luck..

I faced the same issue, and fixed it by making some changes to the Camembert source files, I'll make a pull request for that soon.

authors: RayanSaeed amiralishah

repo: remirobert/Camembert


text:
[Feature]: middleware before Remix processes request

What is the new or updated feature that you are suggesting?
Enjoying Remix so far, but there's one key feature I'd like to see for multi-tenant apps: the ability to intercept and modify an incoming request before handing it off to the core Remix runtime which is agnostic of the deployed platform.
The multi-tenant use case is to enable wildcard subdomains which route to a particular nested route structure within the app. For example, foo.myapp.com/bar could be rewritten and rendered as myapp.com/_sites/foo/bar, utilizing the routing structure within /routes/_sites to render the foo tenant's 'website' using the same codebase as the core app.
This behavior can't be achieved within entry.server.ts, since by the point that is called, Remix has already done up-front route matching on the original URL. Any userland code we could write to achieve this rewriting would have to be supplied to the server runtime directly.
Currently, the only working alternative which enables URL rewrite-based multi-tenancy is to modify the platform-specific deployment entrypoint (i.e. /api/index.js for Vercel, etc) to rewrite the URL before Remix gets it. But this only works in deployed environments (not locally), and would have to be rewritten for different deployment targets if you switch.
CC: https://github.com/remix-run/remix/discussions/1475
Why should this feature be included?

Multi-tenancy is very difficult to get right with Remix without it. You either have to include ballooning special-case logic within the routes themselves ("am I on a subdomain tenant site or the main site?" on every route) or customize your deployed platform code to modify the request beforehand and accept not being able to test subdomains on localhost.
The ... obvious competing framework has explicit support for subdomain mult-tenancy utilizing a special 'middleware' concept, roughly similar to what I've requested here.
Subdomain multi-tenancy is increasingly common and a desirable feature for all sorts of sectors, whether it's a B2B dashboard, communication apps for teams, website builders, nocode tools, social network apps, or anything where a user would want to stake a claim on a section of your app.
A request middleware could also prove more useful than just for multi-tenancy or URL rewriting at all. Perhaps you want to add or remove other parts of the request, like headers or cookies.

Another important use for middleware is database connection pooling. We need to be able to ensure the database connections are released back to the pool at end end of the request even if an error is thrown in a loader/action.
So for now we need to use this useDB(async db => {}) wrapper to ensure we don't accidentally run out of PostgreSQL connections. Where the useDB() is a try-finally wrapper like this:
function useDB(fn) {
    const db = POOL.get();
    try {
        await fn(db);
    } finally {
        db.release();
    }
}

This is OKish but it makes loaders and actions needlessly nested:
export const loader: LoaderFunction = async () => {
    await useDB(async (db) => {
        await db.query(...)
    });
};

It would be awesome to have a central place to extend the loader/action context so we could implement something like this:
export const loader: LoaderFunction = async ({ db }) => {
    await db.query(...)
};

@esamattis good use case. It seems like entry.server.ts handleDataRoute could almost do what you need, but it only exposes modifying a response, not doing pre-request setup. There's still the problem of instantiating the pool and putting it into context.
This would be at least feasible to improvise in userland in the meantime, with a custom loader/action higher-order wrapper -
function dbLoader(loaderImpl: (event: Parameters<LoaderFunction>[0], db: DbPool) => ReturnType<LoaderFunction>): LoaderFunction {
  const loader: LoaderFunction = (event) => {
    return useDB((db) => {
      return loaderImpl(event, db);
    });
  }
  return loader;
}

// ...

export const loader = dbLoader(async ({ request }, db) => {
  await db.query(...);
});

I think user land middleware should be now possible with getLoadContext() in the Express adapter which gets access to the Node.js request and response just by listening on the end event of the response object. But that's going to be Express/node.js specific.

It seems like entry.server.ts handleDataRoute could almost do what you need, but it only exposes modifying a response, not doing pre-request setup

Is it executed on loaders and actions too? Seems like it is always doing react rending 🤔

a custom loader/action higher-order wrapper

This is actually pretty good solution but I wonder whether does it get properly removed from the browser builds.
Thanks for the ideas! I'll be investigating/testing these more on next week!

I wonder whether does it get properly removed from the browser builds.

Did some testing and it does not get removed from the browser bundles under public/build but it seems Remix does not remove remove even the plain loader and action code like Next.js does for getServerSideProps. So I guess this is a separate issue (or feature?).

Hm, that's troubling (probably with a second issue). I'd hope that we could introduce composition functions over loaders and actions in userland without any problems.

I was looking for a graceful way to handle subdomain multi-tenant logic. Out of the box support would be much appreciated.
Same goes for language/region/city detection. I can technically use a loader in root.tsx, but I think this logic is application-wide and doesn't necessarily belong to anything related to react.

There is no need for a middleware concept for multi-tenancy apps (see my comment on #1337).

That will only work if route paths match exactly between subdomain situations and non-subdomain - i.e. tenant.my.app/page is the same page as my.app/page.
But if tenant.my.app/page is equivalent to my.app/~tenants/[tenantName]/page or some other structure, the solution is not as simple as just knowing the hostname - you also have to render an entirely different experience for route structures based on that host.
This ballooning complexity problem is what I was referring to in the original issue text. The only simple solution I can see is to rewrite tenant.my.app to my.app/~tenants/[tenantName] before Remix does anything at all. Then multi-tenancy is a 1-line feature tucked away into my middleware and a straightforward nested route quirk, not a sprawling concern spread across every route and loader in the codebase.

@a-type Yes, I agree - in my use case, the routing structure does not change based on different tenants. The ability to perform rewrites in middleware would open more complex use cases and I would also like to see it. If you are on Cloudflare, you could dedicate a worker just for doing the rewrites. So there are workarounds, although I would prefer a native remix solution.

One of the reasons why Remix doesn't support rewriting URLs is that the URL that it's processing must match the URL that is in the address bar. This is because React Router (which Remix is built on) does client-side routing so the server URL must match the client URL.
They would have to include URL rewriting in React Router itself.

Maybe I don't understand the depth of the issue, but wouldn't it be possible to have a middleware/proxy before entering React router?
incoming request -> middlewar/proxy -> remix

The client-side routing definitely complicates things! Seems like the middleware may have to live in RR itself. However, that also means that even solutions like rewriting the incoming HTTP request in your lambda layer won't work, right? It would seem
Remix doesn't have any solution for the kind of use case you see in NextJS' Multi-Tenant demo using their middleware concepts. I'm not sure how NextJS middleware interacts with their client-side routing, but they've specifically showcased this kind of thing which at least validates that Vercel sees the need for this use case enough to commit effort to documenting it.

Just to chime in here, this is also something that would be an appropriate entry point for functionality like Sentry to inject itself on the server. I think the pattern of having something like middleware.server.tsx and middleware.client.tsx could function here as its fairly easy know whats going on at that rate.
Since folks are contrasting to Next.js, I will say that their approach to middleware is good in some situations, but still limiting in others. For example, if you use Google's Identity-Aware Proxy it passes a signed JWT to every request which contains the authentication information.  In an ideal world an app (a Remix app) could parse this and bundle that information up in its hydration phase (middleware?). It could then retain that state in memory to understand if/who the authenticated session is. AFAIK in Next.js the only solution here is to utilize cookies to pass that information. There may be other approaches but it'd certainly be convulated.
Similarly in Sentry we'd want to inject something as a middleware that ideally could access things like routing information, HTTP headers, etc. allowing us to enrich data streams (both for error reporting and tracing). That enrichment behavior would be fairly distinct on the server, but would still be desirable on the client. So while it's certainly possible you could come up with an API that lets you write-once-run-everywhere middleware, I personally would be fine with having an implementation for each runtime.

authors: a-type dcramer esamattis kiliman miraage styxlab

repo: remix-run/remix


text:
[Bug]: Could not locate @remix-run/serve on npm run dev

Which Remix packages are impacted?

[ ] remix (Remix core)
[X] create-remix
[ ] @remix-run/architect
[ ] @remix-run/cloudflare-workers
[ ] @remix-run/dev
[ ] @remix-run/express
[ ] @remix-run/netlify
[ ] @remix-run/node
[ ] @remix-run/react
[X] @remix-run/serve
[ ] @remix-run/server-runtime
[ ] @remix-run/vercel

What version of Remix are you using?
1.0.4
Steps to Reproduce

npx create-remix@latest
npm run dev
Selected Remix App Server and Typescript

Expected Behavior
It should start a remix server and serve the app
Actual Behavior
It exits the process with an error Could not locate @remix-run/serve. Please verify you have it installed to use the dev command.
More Info:
Node Version - 12.14.1
NPM Version  - 7.19.0
OS:

Please ask out if you need more info.

IDK if this is intentional as this was not mentioned in this official tutorial but it works just fine with node v14. So, I'll be closing this one.

but node 16 occurs the same error

I'm using Vercel template and occurs the same error
▲ remix-storefront (main) ✗ node -v
v16.13.0
▲ remix-storefront (main) ✗ yarn dev
yarn run v1.21.1
$ remix dev
Could not locate @remix-run/serve. Please verify you have it installed to use the dev command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Running into this issue with the vercel template as well. Package wasn't included in the dependencies from the template.

@Tanner-Scadden @franklinjavier sorry! will get a patch release out Monday with this included

Having this issue too, using Vercel.

as a temporary solution, run
npm install --save-dev @remix-run/serve

I'm facing the same issue on node v12

I'm facing the same issue on node v12

@alvaromartmart Remix requires Node version 14 or greater

I'm facing the same issue on node v12

@alvaromartmart Remix requires Node version 14 or greater

Is this documented somewhere? I couldn't find it

@alvaromartmart they have specified it in package.json for the starter templates

sorry about that 😅. fixed in 1.0.6

I'm facing the same issue on node v12

@alvaromartmart Remix requires Node version 14 or greater

we should probably document this somewhere if we haven't already, but we do set the engine in package.json to "node": ">=14"

I'm facing the same issue with remix@1.0.6 and node@16.13.1 but it's working fine with node@14.18.2
I'll keep using node 14 for now but I'd prefer using the current LTS, could we reopen this issue?

but node 16 occurs the same error

For me I updated from node 12 to node 16, then it automatically worked. Maybe you could also try to update npm then clean cache

Node 16 didn't work for me when deploying. I switched to Node 14 and it worked.

Node 15.x and node v16.13.1 doesn't work. This issue should be reopened

Having this issue. Tried all the above with no luck.

Having this issue. Tried all the above with no luck.

Same thing here

Also make sure @remix-run/serve is in your regular dependencies (not just dev dependencies)
Seemed to make a difference on Heroku.

same issue. Coudnt run remix express basetemplate but able to run Indie template which is express template.

Yup just ran npx create-remix@latest ./my-app went with just the basics and express server, installed, built and I am getting this error.

Yup just ran npx create-remix@latest ./my-app went with just the basics and express server, installed, built and I am getting this error.

Just did this recently, and found that it was missing; went looking for a reason and found this... oops...

authors: AvidDabbler Elijah97 Girish21 Tanner-Scadden alvaromartmart cdeutsch coreybruyere franklinjavier girishk21 jmims-magnusdigital ksorv kushalmahajan m5r mcansh oluwatobiadegoke rashidtvmr rjgux sbodi10 willin


text:
fix(create-remix): escape [ and ] in .gitignore

Make /functions/[[path]].js ignored by git in cloudflare-pages template project.

Thanks @supachaidev I'll get this merged.

authors: jacob-ebey supachaidev


text:
fix(remix-dev): flat route fixes and enhancements

Signed-off-by: Logan McAnsh logan@mcan.sh

Closes: #5170
Closes: #5261
Closes: #5303
Closes: #5322
Closes: #5324
Closes: #5327

[ ] Docs
[x] Tests

Testing Strategy:
updated current tests

Fixed my issues perfectly! ❤

Same for me. Perfect !
Good job team ! 🎉

authors: MajorTom327 mcansh silvenon


text:
docs: small updates

Follow-up of @ryanflorence's docs changes
Closes #7441

Left a few minor comments - let's get those addressed and merge this.  It's a bit too big to really give it a close look so let's merge it and then if anything surfaces from the community we can adjust as needed.  We may want to keep these docs updates a bit smaller in the future so they're easier to review :)


text:
「現像」タブに移った後の操作が正しく認識されない

MIDI2LRのバグの可能性もあり。

0.64-preXで対策できた？

0.64にて対策できたと判断。


text:
How to refresh area on a view in the content area

I want to know how to refresh only an area on a view displayed in main content area of the application (like regions with marionette.js).
I loaded some datas in my controller method and I want to switch to another controller method without refreshing all the content of the view.

i tried to call a model in to global/header view but couldn't figure it out. @spikebrehm Can you please   provide a way to do this ?

repo: rendrjs/rendr


text:
Collaboration request

Hello, we are making a universal bot to automate websites.
We would like you to collaborate with us since there are few developers who maintain the project.
https://gitlab.com/universales/rentabilidades-team
We are still developing the new version of the program, but you can try our old version from this link.
https://rentabilidadesweb.runkodapps.com/
Cheers

Hey, I checked the GitLab and it looks like an interesting project, but I do not know any Spanish.  Let me know how I can help. You can definitely use code in this repository, but it does not seem like you are using puppeteer

Hey, I checked the GitLab and it looks like an interesting project, but I do not know any Spanish.  Let me know how I can help. You can definitely use code in this repository, but it does not seem like you are using puppeteer

We have just translated the project into English (In the files) so we can better collaborate.
I recommend that you join our telegram group to better talk about all this.
https://t.me/joinchat/HT1hQBCCxBW3HG8c
The idea for now is to separate all functions from
"/public/core/resources/libglobal.js" and leave the functions inside folders, such as the folder "/public/core/resources/human-simulator/click.js"
(More than anything to have the project well organized).
Cheers

We have just translated the project into English (In the files) so we can better collaborate.
I recommend that you join our telegram group to better talk about all this.
https://t.me/joinchat/HT1hQBCCxBW3HG8c
The idea for now is to separate all functions from
"/public/core/resources/libglobal.js" and leave the functions inside folders, such as the folder "/public/core/resources/human-simulator/click.js"
(More than anything to have the project well organized).
Cheers

We have just translated the project into English (In the files) so we can better collaborate.
I recommend that you join our telegram group to better talk about all this.
https://t.me/joinchat/HT1hQBCCxBW3HG8c
The idea for now is to separate all functions from
"/public/core/resources/libglobal.js" and leave the functions inside folders, such as the folder "/public/core/resources/human-simulator/click.js"
(More than anything to have the project well organized).
Cheers

We have just translated the project into English (In the files) so we can better collaborate.
I recommend that you join our telegram group to better talk about all this.
https://t.me/joinchat/HT1hQBCCxBW3HG8c
The idea for now is to separate all functions from
"/public/core/resources/libglobal.js" and leave the functions inside folders, such as the folder "/public/core/resources/human-simulator/click.js"
(More than anything to have the project well organized).
Cheers

authors: renowator wuniversales


text:
现在的代码编译一堆警告

现在的代码编译一堆废弃警告信息，还有两个分析警告，看着挺受不了的。能不能解决下

运行的时候还有很多自动布局错误提示

repo: renzifeng/ZFPlayer


text:
fix connectionResponse parts

auth_required, tls_required and tls_verify does not exist in version 2.1.7

Is this project abandoned?

authors: Huholoman farmad

repo: repejota/phpnats


text:
Preserve URLs, slugs, and paths

WHAT
URLs, slugs, and file paths should remain unchanged during content processing.
WHY
Maintaining original URL structures is crucial for SEO, existing links, and overall site architecture.
HOW

Create a whitelist of fields (e.g., 'url', 'slug', 'path')
Implement logic to skip processing for these fields
Add tests to verify that these values remain constant

Additional Context
No response

Done.

repo: replexica/replexica