[BUG] do not output error message for connections closed due to timeout

What does this PR do?
This PR fixes https://github.com/elastic/beats/issues/40824
It does not output Error message when reading from a network that closed due to timeout
Why is it important?
Avoid polluting log with unnecessary errors

Checklist

[ ] My code follows the style guidelines of this project
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added tests that prove my fix is effective or that my feature works

:green_heart: Build Succeeded

Buildkite Build
Commit: f6a0c7b5f6fb7a67da1967232590948bf195ece7

:green_heart: Build Succeeded

Buildkite Build
Commit: 42cede595547f8b422b7f30890a344ec89c58511

History

:green_heart: Build #432 succeeded f6a0c7b5f6fb7a67da1967232590948bf195ece7

:hourglass_flowing_sand: Build in-progress, with failures

Buildkite Build
Commit: 8e14431b6936b3540cbf3fe1ad4400307038f656

Failed CI Steps

:linux: Test Linux

History

:green_heart: Build #469 succeeded 42cede595547f8b422b7f30890a344ec89c58511
:green_heart: Build #432 succeeded f6a0c7b5f6fb7a67da1967232590948bf195ece7

:green_heart: Build Succeeded

Buildkite Build
Commit: bd5ba8dbf6dd513e5c697a477c8fae3a609b6d24

History

:broken_heart: Build #475 failed 8e14431b6936b3540cbf3fe1ad4400307038f656
:green_heart: Build #469 succeeded 42cede595547f8b422b7f30890a344ec89c58511
:green_heart: Build #432 succeeded f6a0c7b5f6fb7a67da1967232590948bf195ece7

:green_heart: Build Succeeded

Buildkite Build
Commit: 926e0a62a26596817f174e3871c4cb7c53e29789

History

:green_heart: Build #478 succeeded bd5ba8dbf6dd513e5c697a477c8fae3a609b6d24
:broken_heart: Build #475 failed 8e14431b6936b3540cbf3fe1ad4400307038f656
:green_heart: Build #469 succeeded 42cede595547f8b422b7f30890a344ec89c58511
:green_heart: Build #432 succeeded f6a0c7b5f6fb7a67da1967232590948bf195ece7


Support webm and add new pack

Hi.
A friend https://www.facebook.com/groups/379533023004717/user/100000544281866/ offered some of his work, but it's webm.

[ ] Add support to webm
[ ] Add the pack in the zip

Thank you for the great module.
turnmaker.zip

https://user-images.githubusercontent.com/4999783/117983356-41834200-b30d-11eb-8e76-94ad4224b08e.mp4

Demo

Before adding this to the module I need direct confirmation by the creator that I have their permission to use this. In the mean time you can just store this in your local directory and direct Next Up to that file

Webm is now working. How can I do it?
You can send him a message at facebook.

Webm should work by default. Just select the file through the default file picker

I don't know what I'm doing wrong.  Do you need more?

All good, thanks 👍

@kandashi can you tell me the best settings for these videos? Do you want something especial? Do you like to suggest a theme?

I removed the cyberpunk one
turnmaker.zip

closed by #79


Optimize varLib IUP mechanism

Opening this so other interested parties can jump in. Will switch to a PR as soon as I have something to show.

I came to say we should use complex in that code. Looks like we do for a couple hotspots. I'm guessing that more can be done.
Other than that, more algorithmic analysis.
Also, currently the optimizer works separately from the compiler. There's synergy in doing them together. Let alone that the IUP optimizer does not consider the effect of sharedPoints in the compiler. So it cannot truly optimize across multiple TupleVariations of a glyph.

So.. fully considering the impacts of sharedPoints in the IUP optimizer sounds much harder. If we can't do that anyway, another option is to move the IUP optimizer call into the delta-rounding of the varLib model. Ie. use it as the round function for deltas. That way, the error introduced by IUP optimizer will be folded and accounted into the rounding error, such that the total error is bounded (because of #2214) AND possibly smaller fonts because IUP will see deltas before rounding, so more points can potentially be eliminated.

This has been giving me quite a headache. The current implementation is O(n^3), n being the number of points in a contour. I know of a way to do it O(n^2), but it's superbly ugly, specially to be done in Python. Moreover, to do a good job, we really need to receive unrounded deltas, and produce rounded deltas. That is, this should be done as the round method passed to model.getDeltas(). However, that also means that it should produce the interpolated deltas for whatever delta item it chooses to drop, which makes it ugly and hard to communicate back to model.getDeltas().
I'm lost. Until a breakthrough appears, I'm going to just do microoptimizations on this and possibly disable the slowest part of the algorithm.

Closing in favor of https://github.com/fonttools/fonttools/pull/2269


slugbuilder: Bump buildpacks

https://github.com/cloudfoundry/staticfile-buildpack/compare/8f0d070e...5d6a67be
https://github.com/heroku/heroku-buildpack-ruby/compare/52b7238c...cdef996a
https://github.com/heroku/heroku-buildpack-nodejs/compare/8010e251...5f7dcf14
https://github.com/heroku/heroku-buildpack-python/compare/92b4f5e8...998f996a
https://github.com/heroku/heroku-buildpack-java/compare/ecbd6949...4296d60e
https://github.com/heroku/heroku-buildpack-scala/compare/01ef3f24...a7790893
https://github.com/heroku/heroku-buildpack-play/compare/2a783340...d94c86ad
https://github.com/heroku/heroku-buildpack-php/compare/2c8d01ff...cd2d1399
https://github.com/heroku/heroku-buildpack-go/compare/70eee647...91c7eeae

LGTM


Theming support is back ;)

Hey Clément! :)
I'm back for at least some visual stuff, as I lack the pure coding skills...
There are three themes as of now:

the original one
black on white
white on black

$theme-used variable can be changed in client/src/assets/scss/_variables.scss to choose the theme.
Sadly i was not able to make the themes dynamic, so they need to be specified before the build process.
Please have a look and let me know if something is to change.
Also I saw you have been working on a go version, will check it out too.
Cheers again for this wonderful piece of software.

Look forward to testing this out!
It'd be awesome if this were dynamic from the config.yml file

Should be doable, we just need to parse and push the theme variable from the yml conf to the service i guess. However not sure how to proceed

@BankaiNoJutsu , I'm really sorry but this PR is unlikely to make it through as I'm about to finish rewriting the UI once again to simplify it and use the official material-ui library for React to have a better looking and a smoother user experience.
By the way, theming is given by the library itself so that it's also easier to manage for future themes development. Moreover, the theme will be switchable at runtime if needed in the future.
Returning to your PR, I'm really sorry but this time is the last time I refactor the frontend so deeply. This refactoring is kind of an enabler I would say. It'll come up in a couple of days, I'm at the end of it. I'd be very happy to have your feedback (as well as @davama ) on the default theme and the user experience then. If you're not yet on Gitter, I invite you to join and have a chat!
Sorry again...


Fix selective update for Paket 2.0

Thx for taking care of this. It's really really cool to have someone helping with this.

No man, thank you.
We're switching to paket and we are seeing our update-package workflow changing from a half hour to a few seconds to complete.
Updating a package with paket is like this:


Error when specifying AttachDbFileName in connection string

When specifying AttachDbFileName in connection string, the following error appear: Unable to Attach database file as database xxxxxxx.
Please advise.
Thanks

Please provide more details about your issue.

I am trying to use migration commands to generate database: "dnx . ef migration apply". I get an error saying the database file cannot be attached as database xxxx but if I remove the "AttachDbFileName" section, it works fine and the database file is created in default location.
Please see my code in ConfigureServices.
public void ConfigureServices(IServiceCollection services)
{
var connection = @"Data Source=(LocalDB)\mssqllocaldb;Integrated Security=True;Initial Catalog=SampleDb;AttachDbFileName=D:\SampleDb.mdf";
services.AddEntityFramework().AddSqlServer().AddDbContext(options => options.UseSqlServer(connection));
}

Thanks for updating. This is not a bug in EF 7. We pass-through the connection string to SqlClient. There may be a problem with your localdb setup.

Cross-reference: Cannot attach database file when using Entity Framework 7 Migration commands (on StackOverflow)

I still think this is a bug, or a missing feature compared to EF6. It's quite annoying anyway.

EnsureDeleted changes the database name to master but keeps any AttachDbFileName value, which leads to an error since we cannot attach the master database to another file.
EnsureCreated opens a connection using the provided AttachDbFileName value, which leads to an error since the file of the database we want to create does not yet exist.

EF6 seems to have some logic to handle this stuff, see SqlProviderServices.DbCreateDatabase. And working with Local DB requires using AttachDbFileName if we don't want to bloat our user profile (as far as I know). Maybe updating SqlServerConnection.CreateMasterConnection to remove AttachDbFileName would be the first step to resolve this?
I posted a hacky workaround for this at the stackoverflow question linked by @bricelam...

@axelheer That sounds like a bug. Could you submit a new issue?

It seems the original report might have just missed a few details, but it could have been the same issue that @axelheer is describing from the beginning. I will just reactivate for now.

Beside not stripping AttachDBFileName, we also don't support creating new attached databases. We'll need to produce DDL like the following.
CREATE DATABASE [MyDatabase]
ON (NAME = 'MyDatabase.mdf', FILENAME = 'C:\Path\To\MyDatabase.mdf')
LOG ON (NAME = 'MyDatabase_log.ldf', FILENAME = 'C:\Path\To\MyDatabase_log.ldf');

Yeah, makes sense. Thus, we need already three things:

Remove AttachDBFilename when connecting to master (#6435)
Accept error 1832 within SqlServerDatabaseCreator.Exists or check via dbo.sysdatabases or via db_id(.)
Add file name to SqlServerCreateDatabaseOperation or the like

I've already looked into your tests, but I've no idea how to write some kind of integration test to play through this whole scenario.

FYI, all the logic for resolving paths was in SqlProviderServices.GetOrGenerateDatabaseNameAndGetFileNames for EF6.

I may be able to solve that. Should I dive into it and prepare a PR?

That would be awesome if you're willing!

Okay, I'll give it a try then.

Triage: if we don't take a PR to have proper support in 1.1, the scope for the EF team would be to try to throw a better error.


Append instead of create log file so that it is possible to logrotate.

In long running environment log files can grow without bound because of persistent error and can destabilize the system by filling up disk space. It is usefully to manage log files growth by automatic rotation, compression, removal, and moving them. It is not possible to rotate log file if ">" is used, changing the startup script to use ">>"  which allow to log file file management.

👍

my bad i merged this too fast thought, @tkyaw did you filled a CLA ? http://druid.io/community/cla.html ?

@b-slim Should be under existing corporate CLA, I have requested to add my name under it.


DropdownButton overflow issue when onChanged is null

When DropdownButton is given a null argument for the onChanged parameter (or when no argument is present), a render error occurs with an infinite horizontal overflow.
Steps to Reproduce
return Container(
  width: 500,
  height: 500,
  child: DropdownButton<String>(
    //onChanged: (str) {},   // This line fixes the problem
    value: 'abc',
    items: [
      DropdownMenuItem<String>(
        child: Text(
          'abc',
          overflow: TextOverflow.ellipsis,
        ),
        value: 'abc',
      ),
    ],
  ),
);

Logs
I/flutter (26419): ══╡ EXCEPTION CAUGHT BY RENDERING LIBRARY ╞═════════════════════════════════════════════════════════
I/flutter (26419): The following assertion was thrown during performLayout():
I/flutter (26419): RenderIndexedStack object was given an infinite size during layout.
I/flutter (26419): This probably means that it is a render object that tries to be as big as possible, but it was put
I/flutter (26419): inside another render object that allows its children to pick their own size.
I/flutter (26419): The nearest ancestor providing an unbounded width constraint is:
I/flutter (26419):   RenderFlex#e51fb relayoutBoundary=up2 NEEDS-LAYOUT NEEDS-PAINT OVERFLOWING
I/flutter (26419):   creator: Row ← Padding ← Container ← DefaultTextStyle ← Stack ← Listener ← _GestureSemantics ←
I/flutter (26419):   RawGestureDetector ← GestureDetector ← Semantics ← DropdownButton<String> ← ConstrainedBox ← ⋯
I/flutter (26419):   parentData: offset=Offset(0.0, 0.0) (can use size)
I/flutter (26419):   constraints: BoxConstraints(0.0<=w<=500.0, 0.0<=h<=400.1)
I/flutter (26419):   size: Size(500.0, 400.1)
I/flutter (26419):   direction: horizontal
I/flutter (26419):   mainAxisAlignment: spaceBetween
I/flutter (26419):   mainAxisSize: min
I/flutter (26419):   crossAxisAlignment: center
I/flutter (26419):   textDirection: ltr
I/flutter (26419):   verticalDirection: down
I/flutter (26419): The constraints that applied to the RenderIndexedStack were:
I/flutter (26419):   BoxConstraints(0.0<=w<=Infinity, 0.0<=h<=400.1)
I/flutter (26419): The exact size it was given was:
I/flutter (26419):   Size(Infinity, 400.1)
I/flutter (26419): See https://flutter.io/layout/ for more information.

I/flutter (26419): ════════════════════════════════════════════════════════════════════════════════════════════════════
I/flutter (26419): Another exception was thrown: A RenderFlex overflowed by Infinity pixels on the right.

Flutter Doctor found no issues.
Versioning information:
[ +186 ms] [√] Flutter (Channel stable, v1.0.0, on Microsoft Windows [Version 10.0.17134.523], locale en-US)
[   +2 ms]     • Flutter version 1.0.0 at C:\src\flutter
[        ]     • Framework revision 5391447fae (8 weeks ago), 2018-11-29 19:41:26 -0800
[        ]     • Engine revision 7375a0f414
[        ]     • Dart version 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)

The easiest solution is to add the isExpanded property to true in DropdownButton
For example:
new DropdownButton(
              isExpanded: true, //Adding this property, does the magic
              items: [
                new DropdownMenuItem(
                    child: Text("Some large text that needs to be wrapped or ellipsized"),
                ),
                new DropdownMenuItem(
                  child: Text("This is another large text that needs to be wrapped or ellipsized"),
                ),
                new DropdownMenuItem(
                  child: Text("And one more large text that needs to be wrapped or ellipsized"),
                )
              ],
              onChanged: (val) {
                //print(val);
              }),

@rajyadavnp This issue has been fixed, and no work-around should be necessary.


Achievements - pollAchievements treats EarnedAchievement as Achievement

Server returns EarnedAchievement:
https://github.com/codecombat/codecombat/blob/master/server/users/user_handler.coffee#L316
Client treats as Achievement:
https://github.com/codecombat/codecombat/blob/master/app/models/CocoModel.coffee#L363

Fixed in d69c5941b337854d9b9617ee5b473201b32257f4


Fixed StorageAccount key command

The script used the classic get-azurestorageaccountkey command when referencing an ARM object. Replaced with get-AzureRMStorageAccountKey

Hi @mahedley, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

@nitinme
Please check the content change here, and let me know whether I should accept the PR.

@mumian
Passing this on to Jonathan because he has been looking more into the HDI docs lately.

The article has been updated long time back.  You can close this request.

@mahedley
Thank you for this suggestion. The updated article included these ideas.
--Carolyn


Use full name for references

file "Constants/Numbers.purs"
module Constants.Numbers (x) where
x = 1

x should have the path Constants.Numbers.x as its fully qualified name

https://github.com/purescript/purescript/blob/48634d05da1021ac1bcb4907461ae9b2d3b0e699/src/Language/PureScript/Ide/Types.hs#L299-L313
link to code in the language server


Update substrate to polkadot-v0.9.23

cargo update -p sp-std --precise fe5bf49290d166b9552f65e751d46ec592173ebd

waiting for evm 0.36.0 to be released firstly if we release a new version of frontier

Please pull master.


Modify return value in comparison challenge

Pre-Submission Checklist

[x] Your pull request targets the staging branch of FreeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm test. Use git commit --amend to amend any fixes.

Type of Change

[x] Small bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[x] Tested changes locally.
[x] Closes currently open issue (replace XXXX with an issue no): Closes #11663

Description

These changes modify the seeded code and tests for the challenge "Comparison with the Less Than Or Equal To Operator". The else statement previously returned "25 or More", but now returns "More Than 24" to more accurately describe the values that pass through the else statement.

LGTM 🎉
Thanks a lot for contributing to Free Code Camp!
This is a first for both of us, it's the first time I'm merging a PR. Let's hope all goes well! 😅

@systimotic Congrats to both of us! 🙌

lol you two.


[GMOD] Graceful shutdown not working properly

When stopping a Garry's Mod server, the script gets stucked in an endless loop:
[ .... ] Stopping gmod-server: Attempting graceful shutdown: 453

Gmod does not quit but tries to restart which leads to fn_stop (waiting for the server to exit) to never leave the loop.
I don't know if this is a common error but maybe there are others out there experiencing the same problem.
I found a way arround this by editing the exit condition of the while loop in fn_stop (line 131):
while [ "${pid}" != "0" -a $counter -lt 120]; do
...

I think there are better solutions but it works like expected and exits the loop after 120 seconds if a graceful shutdown is not possible, just killing the tmux session.

Thanks for highlighting this. Your solution will work. I will fix this.

https://github.com/dgibbs64/linuxgsm/commit/5d3469c7b8ba4854f7dcb96bc1745a9ba3d1e035


Charging Station: Add a flag named 'inactive'

How that flag is going to be mapped with OCPI statuses ?
For example, if a charging station is public and made inactive, the OCPI code should also change the status pushed: let it public but with inoperative status?

This is the second step we have to discuss, should an inactive charger should refuse the authorization, block the notifications when offline, not being displayed...

Ok.
I think the same goes for other extra statuses flags added to charging station data structure like deleted, etc.: the OCPI code does not seem to be handling them at all.

I think the same goes for other extra statuses flags added to charging station data structure like deleted, etc.: the OCPI code does not seem to be handling them at all.

Yes, we have to fill the gaps of unfinished job ;-)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: LucasBrazi06:x: LiamLiam seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Navigation

Hey!
Here is an example of how to handle navigation in your Expo and Next.js universal app.
How to think about it:

Use URLs to name your routes
pages folder contains your navigators
screens folder contains your screens
Next.js <Component /> is passed as a screen in the bottom tab bar
NavigationContainer linking contains a mapping of your navigators and screens

Known issues on Next.js:

[ ] Tree shaking issue with React Native Web caused by React Navigation and React Native Bottom Sheet
[x] Dripsy anonymous arrow function causing Fast Refresh issues (edit: fixed with "dripsy": "^3.1.0")

Do you have any recommendations on how to handle auth/unauthed state?
Right now I think I'm going to try to render a protected and unprotected navigator based on the current user state where the BottomTabNavigator is being rendered in the Navigation component.
Interested to see if you have any insight on this.

I actually use per-screen blockers. I find this a lot easier:
<AuthenticatedScreen>
  <Profile />
</AuthenticatedScreen>

AuthenticatedScreen uses the auth context to show an auth flow if the user hasn't completed onboarding, etc.
And then, I just show different tab bars based on the user state:
<Navigator>
  <Screen name="profile" options={{ tabBarButton: user ? undefined: () => null }} />
</Navigator>

Here, the profile tab still is there, but we've hidden the button to open it.
I like that method since it allows a user to visit /profile, for example, without breaking linking. And if they aren't signed in, then it'll just show the sign in screen.
If you set a different linking config altogether, then handling deep links from an app on first won't work. The auth state is set asynchronously, but you still want to be able to handle links on the app's mount.
You can read more about this here: https://www.notion.so/satya164/Handle-deep-link-auth-in-React-Navigation-92e4a29202dc41738b14e7a3fb35e95f
It's not officially solved yet, but I've found hiding the tab to be a good method for auth for now.

It's a good way to do this too!
It depends on the navigation you want but you can get the auth state (current user id) synchronously with MMKV.

Hi thanks for providing this example. How would I configure the Drawer Navigator? I've tried adding universal-tab-navigator/index.web.tsx and have that import createDrawerNavigator from @react-navigation/drawer but the children mapping doesn't seem to work w/ the if (nextRouter && Component) { block.
When I remove that check it works, but the routing in the url does not update when I select a route in the drawer.

I made a drawer, I’ll share it tomorrow

Here's a PR with a drawer navigator that works with Next.js too: https://github.com/axeldelafosse/expo-next-monorepo-example/pull/12
It's not entirely clear how to handle the header for this, but that's a common issue with React Navigation. So I added a small solution, and I'll leave it up to you to figure out the header.
Chances are, in the headerLeft of the Stack, you would have something like:
<Stack.Navigator
  screenOptions={({ navigation }) => ({
    headerLeft(props) {
      if (props.canGoBack) {
        return <HeaderBackButton {...props} navigation={navigation} />
      }

      return <HamburgerButton onPress={() => navigation.dispatch(DrawerActions.openDrawer())} />
    }
  })}
/>

But I didn't include this, since this is pretty specific to those using Drawer navigation.

I added another improvement to the drawer; it now prefetches Next.js routes when you hover.

It's possible to have SSR with your solution ?
Without SafeAreaProvider and with a StackNavigator from @react-navigation/stack, server load the good page, html look ok but I have this error on the client,

react-dom.development.js?61bb:67 Warning: Prop style did not match. Server: "margin-right:16px;margin-left:16px;max-width:-32px" Client: "margin-right:16px;margin-left:16px;max-width:2035px

Looks like a problem to match the screen size between server and client.
If I add SafeAreaProvider on the top of my App, no error on the client but the server doesn't load the page and the childrens of SafeAreaProvider.
If I set initialSafeAreaInsets for SafeAreaProvider it's work but the "Warning: Prop style did not match" come again.

I find this a bit hard to follow. I have a background of Web Dev, whose exposures are only with Next.js and React. Coming from the impressive Rojo's Next Conf talk, and some 2 days of research with the Native ecosystem and then this Navigation example, I would say:

I find it somewhat hard to understand the navigation in this branch, with the introduction of useRouter, which is a file, not a library, that didn't show up in Rojo's talk. Now between Rojo's Nav library and this branch's useRouter, I don't know what to choose.
This branch introduces Linking from React Native. I suppose that's normal knowledge of a RN dev, but I don't even have an idea what Linking is. And I stumbled upon React Native's docs, Expo's docs, and then the React Navigation's docs, now confused about the design decisions of Linking in this branch. Specifically the <LinkTo> component, which I couldn't interpret from any of the above documents.

As a "newbie" of this stack, I apologize for the lack of understanding from my side. Though, as a Web Dev, I am more than committed to switch to this stack for all of my future projects. Making this an entry to Native development, as has convinced me by Rojo's talk, is a totally viable option, and I already see a whole set of tutorials around these kind of monorepos. And I don't like having to choose from options, just like in the situation of choosing a Linux distro. I hope to get "best practices" advice from you all, "the pioneers" shall I say, or else we could end up with about 10 likewise monorepos.
(yes, I'm looking this and Rojo's monorepo. Navigation is already at the contradict zone now.)

I’m on my phone so I’ll give a longer-winded answer soon, but the best I can say for now is: I agree.
This branch is a bit of an experimentation of the next steps for truly unifying the API. It’s near stable, but I’m changing and testing things in my app from it all the time. The goal here is to provide a much better level of navigation abstraction.
Once I feel confident in this branch, most of this code will actually move into my library and will be totally abstracted. But at the moment, I’m still figuring some things out, so I empathize with you on the DX.
Bare with us though, it’ll be worth it :)

Sorry about that! It's very much a WIP indeed.

This branch is a bit of an experimentation of the next steps for truly unifying the API. It’s near stable, but I’m changing and testing things in my app from it all the time. The goal here is to provide a much better level of navigation abstraction.

Me too, I'm actively working on an app and evolving the way we handle navigation very often. Releasing this now would mean a lot of breaking changes.
Once we find a good solution and that we use it in production, we will be able to release it.

Do you have an ETA?

Once we find a good solution and that we use it in production, we will be able to release it.

Beginning of January. Maybe sooner 🤷♂

Axel and I are collaborating on this stuff everyday as we build it into our own production apps. There are many details to get right.

As a minor update, I feel that I've been making very good progress on this. I'm navigating across my entire app, with URLs only. All my URLs (and their query params) are typed via codegen. Shallow routing is working, with code splitting. Stack modals are working smoothly cross-platform.
I think the advice will be to organize your navigation in a strict way that keeps navigation simple, not too nested, and scalable. It will be opinionated and (hopefully) well documented.
Here's how it will work. You will use 1) a "navigation wrapper", and then 2) a set of stack navigators.
A navigation wrapper is a drawer navigator or a tab navigator. These will exist in place of the common <Layout /> component people use in _app.js-type files in in web projects.
Drawers and tabs are the two most common UI patterns for web and mobile. Every website typically has a header, where its navigation is handled, or bottom tabs, or a sidebar + drawer (based on screen size).
Any one of those options will classify as your app's wrapper.
Okay, once we have our wrapper chosen, we need to determine what goes inside of each of its screens.
Every one of your wrapper's screens should be a single, flat Stack navigator. No nested stacks.
For instance, if you choose to use a drawer, then each "screen" item of your drawer will be a single stack.
How does this play out with Next.js?
In your _app.js, you will render your singular <DrawerNavigator />.
I've created a DrawerNavigator (and BottomTabNavigator) wrapper that is tailored to Next.js in particular.
You will pass it Component and pageProps from your _app.js:
<DrawerNavigator Component={Component} pageProps={pageProps} />

On native, it will render the actual stack you pass it (more on this in the docs later).
On Web, it will render Component, which comes from your Next.js page file.
So now, onto the stack part.
Like I said before, each wrapper screen is a stack. What does this mean practically?
In the case of Next.js, it means that every single Next.js page is a React Navigation stack.
// pages/artists/[slug] & pages/artists use the same component here

export default function ArtistPage() {
  return (
    <NativeStack.Navigator screenOptions={screenOptions}>
      <NativeStack.Screen
        name="artist"
        component={ArtistScreen}
        getId={({ params }) => params?.slug}
      />
      <NativeStack.Screen
        name="artists"
        component={ArtistsScreen}
      />
    </NativeStack.Navigator>
  )
}

I'll elaborate more on this in the future. But if you're already familiar with React Navigation, I encourage you to start thinking in this way: create a single navigator at the root (drawers or tabs), and then make each one of its screens a single flat stack.
Chances are, on Native, we will have one stack navigator singleton that will get used on every tab. The only difference will be its initialRouteName. And on Web, we will render a given stack per-page, optimized for both code-splitting and shallow modal stacks.
To get around pages, you will always do something like this:
router.push(pagesPath.artists()._slug('drake').url())

// or
<Link href={pagesPath.artists()._slug('drake').url()} />

We will navigate around using identical APIs, all URL-based.
And if you've read this far, I'm assuming you've already watched my talk: https://www.youtube.com/watch?v=0lnbdRweJtA

In the spirit of sharing works-in-progress, here is a universal Link component: https://gist.github.com/nandorojo/e0b09c17571f6e7852f9ba265a566c36
It also comes with TextLink.
In the future, these will be exported by my library.
The API is exactly the same as next/link. Make sure you have your linking config setup for React Navigation, which should match that of your Next.js pages (like in this PR). That'll be more clearly documented in the future, but if you look on React Navigation's docs for linking config it's pretty straightforward.

Updated useRouter to support query params inside of push and replace.
const router = useRouter()

// these are both valid
router.push({ path: '/artists/[slug]', query: { slug: 'drake', from: 'search' })
router.push('/artists/drake?from=search')

I'll elaborate more on this in the future. But if you're already familiar with React Navigation, I encourage you to start thinking in this way: create a single navigator at the root (drawers or tabs), and then make each one of its screens a single flat stack.

Have you thought about being able to use both tabs & drawers?
To my understanding of React Navigation, either one of those should be nested within the other. So for example you could have the drawer be the top level with the tabs being a stack within the drawer.
However, this seems to go against the recommendation of having only single flat stacks nested in the top-level navigator?

@peterferguson do you have an example of what the linking config would look like if you used both navigators?

@nandorojo I am pretty new to all this, so if this doesn't make much sense then my apologies!
My linking config looks something like this:
...
config: {
    screens: {
      [tabPaths.enterTab]: {
        path: "",
        initialRouteName: enterStackPaths.enter,
        screens: { [enterStackPaths.enter]: "enter" },
      },
      [tabPaths.groupsTab]: {
        initialRouteName: groupStackPaths.groups,
        path: "groups",
        screens: {
          [groupStackPaths.groups]: "",
          [groupStackPaths.groupSettings]: ":id/settings",
          [groupStackPaths.group]: ":id",
          [groupStackPaths.new]: "new",
        },
      },

     ... (more tab paths)

     // - These are the top level paths
      [mainPaths.onboarding]: {
        path: "onboarding",
        screens: { [onboardingStackPaths.onboarding]: "onboarding" },
      },
      [mainPaths.settings]: {
        path: "settings",
        screens: {
          [settingsStackPaths.settingsScreen]: "settingsScreen",
          [settingsStackPaths.profileSettings]: "profileSettings",
          [settingsStackPaths.personalSettings]: "personalSettings",
          [settingsStackPaths.notificationSettings]: "notificationSettings",
          [settingsStackPaths.FAQSettings]: "FAQSettings",
        },
      },

The mainPaths are then sitting in the top-level navigator like so
    <Drawer.Navigator
      screenOptions={{...}}
      useLegacyImplementation={Platform.OS === "web"}
      drawerContent={props => <DrawerContent {...props} />}
      Component={Component}
      pageProps={pageProps}
    >
      <Drawer.Screen
        name="main"
        component={MainNavigator}
      />
    </Drawer.Navigator>

where the MainNavigator looks like
    <MainStack.Navigator
      initialRouteName={"withBottomBar"}
      screenOptions={{ headerShown: false, ...headerScreenOptions }}
    >
      <MainStack.Screen
        name="withBottomBar"
        component={BottomTabNavigator}
        options={{ headerShown: false }}
      />
      {clientReady && (
      <MainStack.Screen
        name="settings"
        component={SettingsNavigator}
        options={{ headerShown: false }}
      />
      )}
    </MainStack.Navigator>

This is probably not optimal, but it is working for me so far on expo (haven't actually checked it out on NextJs side yet).

I mean, it seems like that could work. For example, Twitter has a hamburger menu and bottom tabs on its native app too. But I figure the drawer it has is just a UI wrapper, and when you click one of the links in the drawer, it just opens a screen in your current tab. Not sure though 🤷♂
If you can manage to get that to work in Next.js too, then it should be fine. I might keep my recommendation simple still, but it's still just a recommendation.

Do you have any recommendations on how to handle auth/unauthed state?
Right now I think I'm going to try to render a protected and unprotected navigator based on the current user state where the BottomTabNavigator is being rendered in the Navigation component.
Interested to see if you have any insight on this.

I actually use per-screen blockers. I find this a lot easier:
<AuthenticatedScreen>
  <Profile />
</AuthenticatedScreen>

AuthenticatedScreen uses the auth context to show an auth flow if the user hasn't completed onboarding, etc.
And then, I just show different tab bars based on the user state:
<Navigator>
  <Screen name="profile" options={{ tabBarButton: user ? undefined: () => null }} />
</Navigator>

Here, the profile tab still is there, but we've hidden the button to open it.
I like that method since it allows a user to visit /profile, for example, without breaking linking. And if they aren't signed in, then it'll just show the sign in screen.
If you set a different linking config altogether, then handling deep links from an app on first render won't work. The auth state is set asynchronously, but you still want to be able to handle links on the app's mount.
You can read more about this here: https://www.notion.so/satya164/Handle-deep-link-auth-in-React-Navigation-92e4a29202dc41738b14e7a3fb35e95f
It's not officially solved yet, but I've found hiding the tab to be a good method for auth for now.

@nandorojo in your example, is AuthenticatedScreen something like this?
const AuthenticatedScreen = ({children}) => {
if (!user){
return
}
return(
<>
{children}
</>
)
}

I am using it like this
`
export function Navigation({ Component, pageProps }: NextNavigationProps) {
const trackedLinking = useRef(linking)
const linkingConfig = useLinkingConfig(trackedLinking)
const [user, setUser] = React.useState(undefined)
React.useEffect(() => {
setTimeout(() => {
setUser('abc')
}, 5000)
}, [])
return (
<NavigationContainer
linking={linkingConfig.linking}
onReady={linkingConfig.onReady}
documentTitle={{
enabled: true,
formatter: (options) =>
options?.title ? ${options.title} - Seven : 'Seven'
}}
>

{user ? (

) : (

)}

)
}
`
It is working partially though. When the user is undefined and if I try to access /profile route, then it does automatically change the route to /verify-code and the verification screen is shown, which is perfectly fine. As soon as there's a user, it does navigate me to the tab screen, however, when I try to access /verify-code, it does take me to the verification screen which shouldn't happen. Any workaround for this? The verify-code is the same native stack as home stack.

@RazaShehryar I'm not a big fan of redirects for auth in general. I find that state-based auth, wherever your user ends up, is more robust. And it follows the react model more closely: UI as a function of state.
I don't know if I totally understand the problem you're facing, but here are some thoughts.
You should be able to wrap any given screen to show your auth flows based on react state. Similarly, you can show/hide tabs (or hide the tab bar altogether) based on your auth state.
Would that be an okay solution?
Another downside of using full pages for auth is that your users lose state of the page they're currently on. But this only matters if your app has public/private screens mixed. In general, I use a <Modal /> at the root of my app and open it with context to do auth flows. I know every app is different, but I like this method in general.
If you really want to have different pages for auth flows, what if you just did this:
<AuthenticatedScreen>
  <EveryScreen />
</AuthenticatedScreen>

// ...
const AuthenticatedScreen = ({ children }) => {
  const user = useUser()

  // link to your auth page
  if (!user) return <SignUpForm href="/auth" />

  return <>{children}</>
}

Any method other than this will effectively break deep linking, since you will never have auth state on the initial render of a deep link.

however, when I try to access /verify-code, it does take me to the verification screen which shouldn't happen.

Not sure, my guess is that your linking config might be incorrect here, or you didn't create a Next.js page for that route.

I'm currently doing a mix of both approaches.
We use something similar to what @nandorojo highlights here:
<AuthenticatedScreen>
  <EveryScreen />
</AuthenticatedScreen>

// ...
const AuthenticatedScreen = ({ children }) => {
  const user = useUser()

  // link to your auth page
  if (!user) return <SignUpCTA href="/auth" />

  return <>{children}</>
}

Along with additional logic in this wrapper to only redirect them on the web to a /login route which renders our AuthNavigator.
This seems to be working relatively well so far for us.

@RazaShehryar I'm not a big fan of redirects for auth in general. I find that state-based auth, wherever your user ends up, is more robust. And it follows the react model more closely: UI as a function of state.
I don't know if I totally understand the problem you're facing, but here are some thoughts.
You should be able to wrap any given screen to show your auth flows based on react state. Similarly, you can show/hide tabs (or hide the tab bar altogether) based on your auth state.
Would that be an okay solution?
Another downside of using full pages for auth is that your users lose state of the page they're currently on. But this only matters if your app has public/private screens mixed. In general, I use a <Modal /> at the root of my app and open it with context to do auth flows. I know every app is different, but I like this method in general.
If you really want to have different pages for auth flows, what if you just did this:

<AuthenticatedScreen>

  <EveryScreen />

</AuthenticatedScreen>

// ...

const AuthenticatedScreen = ({ children }) => {

  const user = useUser()

  // link to your auth page

  if (!user) return <SignUpCTA href="/auth" />

  return <>{children}</>

}

Any method other than this will effectively break deep linking, since you will never have auth state on the initial render of a deep link.

however, when I try to access /verify-code, it does take me to the verification screen which shouldn't happen.

Not sure, my guess is that your linking config might be incorrect here, or you didn't create a Next.js page for that route.

Hmm, so instead of conditional rendering whole stack, you are suggesting to add the context to their respective screens. So like if the protected stack has 5 screens, I'll have to wrap it with the general context componentin each of those screens? What are your thoughts on HOC which can be used like this export default HOC(MyComponent)?

you are suggesting to add the context to their respective screens

That’s right.
An HOC does the same thing, so that works! I don’t use HOCs these days, but it’s a matter of preference. I think auth is a good use case.
(PS I know I’m writing kinda long comments so no need to quote the whole thing, makes it a bit hard to follow)

This thing is working fine. However, I also want to change my url to /verify-code.
Right now if I navigate to /profile, it does take me to the auth screen but the url points to /profile. Am I doing something wrong?
This is my AuthenticatedScreen:
const AuthenticatedScreen = observer(({ children }) => {
  const { user } = store

  // link to your auth page

  if (!user.id) {
    return <VerifyCodeScreen />
  }

  return <React.Fragment>{children}</React.Fragment>
})

export default AuthenticatedScreen

Hi guys!
How do you manage the canGoBack option in NextJS? I have a scenario where a user can paste some link directly. And that screen has a close button which has an action of router.back(). However, if I paste the link directly and then press that button, it redirects me to an empty starting page of the browser.

Hi guys!
How do you manage the canGoBack option in NextJS? I have a scenario where a user can paste some link directly. And that screen has a close button which has an action of router.back(). However, if I paste the link directly and then press that button, it redirects me to an empty starting page of the browser.

I have a solution for this. Try this:

Create a custom HeaderBackButton:

Click to view HeaderBackButton
import React from 'react'
import {
  HeaderBackButton as ReactNavigationHeaderBackButton,
  HeaderBackButtonProps,
} from '@react-navigation/elements'

import { useRouter as useNextRouter } from 'next/router'
import { StackRouter } from '@react-navigation/routers'
import { StackActions, getPathFromState } from '@react-navigation/native'
import { NativeStackScreenProps } from '@react-navigation/native-stack'

// this is scary...
// @ts-expect-error but react navigation doesn't expose LinkingContext 😬
import LinkingContext from '@react-navigation/native/lib/module/LinkingContext'
import { LinkingOptions } from '@react-navigation/native'

import { useContext } from 'react'

// hack to access getStateForAction from react-navigation's stack
//
const stack = StackRouter({})

export function HeaderBackButton({
  navigation,
  ...props
}: HeaderBackButtonProps & {
  navigation: NativeStackScreenProps<any>['navigation']
}) {
  const linking = useContext(LinkingContext) as
    | {
        options?: LinkingOptions<ReactNavigation.RootParamList>
      }
    | undefined
  const nextRouter = useNextRouter()

  if (!props.canGoBack) {
    return null
  }
  const back = () => {
    if (nextRouter) {
      const nextState = stack.getStateForAction(
        navigation.getState(),
        StackActions.pop(),
        // @ts-expect-error pop and goBack don't need the dict here, it's okay
        // goBack: https://github.com/react-navigation/react-navigation/blob/main/packages/routers/src/CommonActions.tsx#L49
        // pop: https://github.com/react-navigation/react-navigation/blob/main/packages/routers/src/StackRouter.tsx#L317
        {}
      )
      if (nextState) {
        let path =
          nextState.index != undefined
            ? nextState.routes[nextState.index]?.path
            : undefined

        if (!path) {
          const getPath = linking?.options?.getPathFromState || getPathFromState
          path = getPath(nextState, linking?.options?.config)
        }

        if (path != undefined) {
          return nextRouter.replace(path, undefined, { shallow: true })
        }
      }
    }

    navigation.goBack()
  }

  return <ReactNavigationHeaderBackButton {...props} onPress={back} />
}

Then use it in your screenOptions in your stack:
<Stack.Navigator
  screenOptions={({ navigation }) => ({
    headerLeft: Platform.select({
      web(props) {
        return <HeaderBackButton {...props} navigation={navigation} />
      }
    })
  })}
/>

It's important that you have your initialRouteName defined on your stack, and in linking config.

Quick question.
Has anyone currently had to handle modals w/ the bottom-tab-navigator and a regular stack navigator (not the native stack). I have a unique use case where the mobile app would ideally be used shared element in navigation and therefore required to use a normal stack navigator extended via react-navigation-shared-element.
I'm running into an issue where the normal stack navigators don't seem to be treated as portals and render under the bottom tab navigator forcing me to either hide the bottom tab navigator (Jarring) or I'm currently pondering the idea of moving modals to a root stack on par with the bottom tab navigator.
Look forward to any feedback.

Could you elaborate? Maybe with videos or something? I have used modals, both as screens and as actual modals, in stacks nested inside of tabs. But I might be missing what you’re trying to do.
I don’t think the shared element navigator works on Web FWIW.

Another little update here:

I started moving the navigation code here into its own library called Solito.
I have been using this code and the navigation patterns extensively in production. It's working great

I've been running into a bit of a tricky philosophical question in general: How much should we fit React Native's navigation to Next.js?
A concern I have about publicly setting the best practices is trying to over-fit React Navigation where it may not be necessary.
As I outlined in my original post about truly merging the APIs, there are a few different problems to solve:

Getting around from page-to-page. Solved with Link and useRouter()
What to display (/pages folder vs createStackNavigator() in App.tsx)
Modal screens

I feel that 1 is totally solved, now that I made universal Link, LinkText and useRouter, paired with all URLs triggering from linking on native. So the open questions are 2 and 3.
In a previous comment above, I outlined a structure where you have a root navigator, and nested stacks in each tab.
This is the layout I have been using in my app. It comes with some really great benefits. To name a few pros:

You can easily bring the concept of screen stacks from native to Web. I can't live without this now. You have an artists/ screen, and then open artists/drake, and if you refresh, you can go back, and the stack handles it for you. This is great.
Same goes for modals. You can do artists/drake/edit, and you can go back, and it'll put you in the right spot in the stack. This is super valuable, and it's not a baked in feature or pattern in web dev in general.
Even though you may use different stacks and such on Web vs native, in general, your web and native appear to use the same structure.
You get nice header titles for each

However, this also has some cons. Namely:

React Navigation doesn't have great tree shaking on Web.
React Navigation has opinionated UI for drawers and tabs. I think for stacks this is fine since it's easy to work with. But for drawers and tabs, in many cases, you may not necessarily want to use their UI components. I think this is nice for a starting point, but in some cases it doesn't reflect what you want.
React Navigation on Web forces you to use ScrollViews over window scrolling. This is probably the right thing to do for x-platform parity. But I have run into some cases of wanting window scrolling on mobile browsers to collapse the header and footer.
We have 2 sources of navigation truth: next/router and react-navigation. Technically, next/router is the source of truth, and it fires changes to react-navigation. Is this a feasible way to set a standard for navigation, though?
How do we do marketing vs authenticated pages at the same routes? What if we want a header at the top for marketing, but a drawer navigator wrapping our dashboard? You could have a different website (app.beatgig.com and beatgig.com) but this doesn't work for many apps, like ours.

I have been playing around with a new approach/thought process.
What if (and I'm not sure about this yet) we use react-navigation only on native, and next/router on Web? In this case, each Next.js page would be just that: a Next.js page. We would still share the screen components, Link and useRouter() to trigger page changes.
With this other approach, you would be responsible for adding your own shared Layout component to handle a drawer sidebar, header, and optionally things like back buttons.
For implementing modals, you would use shallow routing with a React Native <Modal />, as is currently recommended in general by Next.js.
Long-story short: I feel that the most important part of sharing code, which is triggering page changes is solved with useRouter + linking config. The missing piece is how to render our shared screens, cross platform, in a way that doesn't sacrifice the optimal implementation for each platform. While sharing code is great, I want to make sure that I don't push everyone to overly abstract to fit two different libraries.
I would need to play with this new approach I'm mentioning a bit more. Luckily, it should actually be pretty easy to implement / change between the two. It would just require returning screens instead of stacks and implementing our own UI instead of drawers/tabs on web. Since our actual source of truth is still next/router for triggering navigation changes, it should be easy to try out both approaches.
If you've read this far, thanks for bearing with me. There is a lot to think about here, and I figured it would be best to share my thoughts as early as possible. Who would have known navigation could be so complicated?
We'll get there soon.

I'm a big fan of the second approach @nandorojo is mentioning, relying on react-navigation only on native and leveraging solely next/router on web.
In my opinion, there are some important foundational differences between web and native navigation. Most importantly probably the concept of self-contained pages (especially with SSR) and how freely you can navigate around the application. Where a mobile app has a very defined and rigid navigation structure with a single entrypoint (the initial route; ignoring deep links), on web I expect to be able to freely navigate to /artists/drake or any other page in that sense.
This is where I see the biggest mismatch between react-navigation: Using stacks like the PlaylistsNavigator and having to manually export it on every route of /playlists/*. If we now navigate to /playlists/1, react-navigation will render both the PlaylistScreen (for /playlists/1) as well as the PlaylistsScreen (for /playlists) which is the initial route in this particular stack. This would also kick off all effects located in PlaylistsScreen unless wrapped in a useFocusEffect or similar. On web, this feels like it's bringing too many not-so-obvious considerations with it. Ideally, a screen would be totally self-contained which fits Next.js' routing paradigm perfectly.
One of the upsides of always rendering a full stack, however, is that we have the ability to goBack() out of the box, since the initial route is rendered in the stack as well. When rendering the PlaylistScreen directly as a page (and directly navigating to it), we would need to manually render a back button taking us to /playlists.
This could maybe be addressed by rebuilding the stack only in the window's history relying only on the linking config.
Further, we could build a set (or wrappers) of the react-navigation navigation components - Header, BackButton, Tabs, Drawer - that instead also rely only on the linking config, in addition to a layout component (call it NavigationContainer) that we can wrap our app with to take care of displaying all of the components as they would be in a react-navigation app.

To demonstrate this further, take an application that has the following structure:

Tabs:

Home (/ - initial route)
Playlists Stack

PlaylistsScreen (/playlists - initial route)
PlaylistScreen (/playlists/1)

Based on the linking config of this app, when navigating straight to /playlists/1:

We can add /playlists to the window's history, based off of which our <BackButton /> is shown.
Our NavigationContainer renders only:

Bottom Tabs for the outer Tab Navigator
Header with BackButton for the Playlists Stack
The current screen based off Next.js' Component available in _app.tsx.

(Note that this would require not using navigation transitions on the web in order to work.)

Instead of trying to fit react-navigation to Next.js, here we could be trying to define a layer above both react-navigation and Next.js that can serve as basis for both yielding quasi-similar results.
To be honest, given the complexity and the sheer number of customization options of react-navigation, I'm not sure how feasible this actually is in practice.

Although I believe that this particular repo has opted out of SSR with dripsy, dropping this here as well for reference:
In order to get react-navigation play nicely with SSR, I had to pass initialMetrics to SafeAreaProvider and also use their fairly undocumented ServerContainer for which I wrote a simple wrapper to handle it only being rendered server-side to hydrate the navigation state:
// server-container.tsx
import React, { useMemo } from "react"
import { ServerContainer as RNServerContainer } from "@react-navigation/native"
import { useRouter } from "next/router"

export const ServerContainer: React.FC = ({ children }) => {
  const router = useRouter()
  const initialLocation = useMemo(
    () => ({
      pathname: router.pathname,
      search: router.asPath.split(/\?/)[1] ?? "",
    }),
    []
  )

  if (typeof window === "undefined")
    return (
      <RNServerContainer location={initialLocation}>
        {children}
      </RNServerContainer>
    )

  return <>{children}</>
}

Then in _app.tsx:
export default function App({ Component, pageProps }: AppProps) {
  return (
    <>
      <Head>
        {/* ... */}
      </Head>
      <ServerContainer>
        <SafeAreaProvider
          initialMetrics={{
            insets: { top: 0, bottom: 0, left: 0, right: 0 },
            frame: undefined as any,
          }}
        >
          <GestureHandlerRootView style={{flex: 1}}>
            <Navigation Component={Component} pageProps={pageProps} />
          </GestureHandlerRootView>
        </SafeAreaProvider>
      </ServerContainer>
    </>
  )
}

@finkef I believe that ServerContainer will break React's SSR hydration.

@nandorojo You mean because of the conditional rendering? The produced HTML is the same, but I'll admit I'm not a pro when it comes to the nitty gritty details of SSR.
The reason I built this conditional wrapper around it was to simply suppress an error log from the component itself: https://github.com/react-navigation/react-navigation/blob/main/packages/native/src/ServerContainer.tsx#L23

I'm going to try my approach mentioned here in production. I'll call it the headless navigation approach.
React Navigation on native, Next Router on Web, mostly code sharing, with a single source of truth. Rather than using stacks/tabs/drawers on Web, you would build this UI yourself.
We can still leverage the headless UI elements from React Navigation (such as Header) on Web if we want.
Here I'll think through how to bring some of the nice native features to Web.
Say we want a common header to live on every page.
In our _app.tsx, we would add the header.
import { Header } from '@react-navigation/elements'

export function App({ Component, pageProps }) {
  return (
    <>
      <Header />
      <Component {...pageProps} />
    </>
  )
}

The thing is, how do we now pass metadata down to the header?
I'm thinking we could add options to a screen component:
// pages/artists/[slug]
export function ArtistPage() {
  return <></>
}

ArtistPage.options = {
  headerTitle: 'Artist'
}

And then apply that in _app.tsx:
import { Header } from '@react-navigation/elements'

export function App({ Component, pageProps }) {
  const { options } = Component
  return (
    <>
      <Header {...options} />
      <Component {...pageProps} />
    </>
  )
}

Sometimes, you want to asynchronously fetch the page title in getStaticProps. We could do that too:
// pages/artists/[slug]
export function ArtistPage() {
  return <></>
}

export async function getStaticProps({ params }) {
  const { name } = await getArtist(params.slug)
  return {
    props: { options: { headerTitle: artist.name } }
  }
}

And then apply that in _app.tsx:
import { Header } from '@react-navigation/elements'

export function App({ Component, pageProps }) {
  // default to Component.options if it exists?
  const options = { ...Component.options, ...pageProps.options }

  return (
    <>
      <Header {...options} />
      <Component {...pageProps} />
    </>
  )
}

The other situation is header back buttons. How do we tell a page if (and where) it can go back to previous page in its "stack".
For example, if I'm on an artist profile, what if I always want there to be a back button to the /search, even if I just refreshed the page?
Perhaps we could add some sort of backToUrl parameter on page components:
// pages/artists/[slug]
export function ArtistPage() {
  return <></>
}

ArtistPage.backToUrl = '/search'

And then we would just tell our header back button to go back to that page:
import { Header, HeaderBackButton } from '@react-navigation/elements'

export function App({ Component, pageProps, router }) {
  const { backToUrl } = Component

  return (
    <>
      <Header
        headerLeft={function headerLeft() {
          const onPress = () => {
            router.push(backToUrl)
          }
          return !!backToUrl && <HeaderBackButton onPress={onPress} />
        }}
      />
      <Component {...pageProps} />
    </>
  )
}

I'm oversimplifying the code a bit, but I think this is a general idea for how it could work. You leave it up to the platform to implement the navigation skeleton that appears around your pages, providing them with self-contained, Web-only components that don't force you to use a library like React Navigation on Web.
For things like useIsFocused hooks and such, we'd have to think through the best solution. But I think this could work.
I'd have to think through how to do modals + URLs on Web. It may be simple. Maybe this part is documented but ultimately solved more in userland.
I'm going to try to migrate some of our code to this method for Web and see how it plays out. Hopefully, we can achieve navigation with a single source of truth while sharing code.

I like where this is going!

The back button for modals could actually be somewhat simple. We could make the backToUrl support a string, or a function that returns the string.
pages/artists/[slug]
export default function ArtistPage() {
  return <></>
}

ArtistPage.backToUrl = '/search'

pages/search
import ArtistPage from './artists/[slug]'

export default function SearchPage() {
  const router = useRouter()

  const openArtist = (slug) =>
    router.push(`/search?slug=${slug}`, `@${slug}`, { shallow: true })

  return (
    <>
      <SearchScreen onPressArtist={openArtist} />
      {!!router.params?.slug && <Modal><ArtistPage /></Modal>}
    </>
  )
}

SearchPage.backToUrl = () => {
  if (Router.params.slug) {
    return ArtistPage.backToUrl
  }
  return null
}

Finally, in _app.tsx:
import { Header, HeaderBackButton } from '@react-navigation/elements'

let canGoBack: boolean // implement this with the web history API + a navigation listener

export function App({ Component, pageProps, router }) {
  const { backToUrl } = Component

  return (
    <>
      <Header
        headerLeft={function headerLeft() {
          const prevUrl =
            typeof backToUrl == 'function' ? backToUrl() : backToUrl
          const onPress = () => {
            if (canGoBack) {
              router.back()
            } else {
              router.replace(prevUrl)
            }
          }
          return (
            (!!prevUrl || canGoBack) && <HeaderBackButton onPress={onPress} />
          )
        }}
      />
      <Component {...pageProps} />
    </>
  )
}

Exploring another idea: What if we exposed a router.setOptions function (similar to that of react-navigation) to allow setting things like backToUrl dynamically? With a HOC, we could also automatically fallback to static props on the component as you have above. Could look something like this:
pages/artists/slug
export default function ArtistPage() {
  return <></>
}

// Will still be used as default
ArtistPage.backToUrl = '/search'

pages/search
import ArtistPage from './artists/[slug]'

export default function SearchPage() {
  const router = useRouter()

  useLayoutEffect(() => {
    // perform some logic that cannot be computed outside the context of this component
    router.setOptions({ backToUrl: ArtistPage.backToUrl })
  }, [])

  const openArtist = (slug) =>
    router.push(`/search?slug=${slug}`, `/@${slug}`, { shallow: true })

  return (
    <>
      <SearchScreen onPressArtist={openArtist} />
      {!!router.params?.slug && <Modal><ArtistPage /></Modal>}
    </>
  )
}

_app.tsx
export function App({ Component, pageProps }) {
  return <NavigationContainer component={Component} /> // "NavigationContainer" for the lack of a better word
}

Can you think of an example where you would need that? You could just keep a custom state variable in _app.tsx and override the options that way if you do, but I’m not totally sure when it would be necessary.
The options as I proposed them are only really adding a header for Next.js with a back button. But it’s actually not unique to React Native — this could work as a paradigm for any next app.

For your last example, instead of setting ArtistPage.header, you should just render the header inside of ArtistPage if you want it to be a unique component. And you could set ArtistPage.options.headerShown = false.
The options should probably only serve to set serializable fields that can be forwarded down as props. If you need page-specific components, simply render them inside the page component.

Do you think that solito would export types for "Screens"? I'm thinking a custom type that set's the navigation prop to optional and extends the base react-navigation types would be a great replacement for the default types exported from react-navigation.
I bring this up because the previous conversation made me think of the many locations we use navigation.setOptions inside an effect at the screen level. It might be easy for someone to make a mistake and leverage this prop thinking it's cross-platform; when in reality it's just on native.

Do you think that solito would export types for "Screens"?

Potentially…we certainly could. I think it may make more sense to have the type documented for users to write themselves since it’s so app-specific, but maybe we can export the type to make it simpler.

I bring this up because the previous conversation made me think of the many locations we use navigation.setOptions inside an effect at the screen level.

Interesting, what are some cases you guys use this for? I’ve actually never used this inside an effect.
Maybe we could export a useSetOptions hook that returns that function, and on Web updates the state you set in _app.tsx. The issue is, then we need to create this context for Next.js, even though it may not be necessary. I’d rather see some use cases of calling setOptions in a hook so I can better understand the need.

FWIW, this is how I’m typing ArtistPage.options for now:

import type { NativeStackNavigationOptions } from '@react-navigation/native-stack'
import type Router from 'next/router'

type Url = Parameters<typeof Router['replace']>[0]

export type NextPageOptions = Omit<
  NativeStackNavigationOptions,
  'headerTitle'
> & {
  previousPagePath?: Url | (() => Url | null)
  headerTitle?: string | (() => string | null)
}

I actually built my own Header component to keep it simple, and I’m only implementing the few props I’m using.

Maybe we could export a useSetOptions hook that returns that function, and on Web updates the state you set in _app.tsx. The issue is, then we need to create this context for Next.js, even though it may not be necessary. I’d rather see some use cases of calling setOptions in a hook so I can better understand the need.

I definitely see the downside for an additional context here. It seems like it could add some complexity.

Interesting, what are some cases you guys use this for? I’ve actually never used this inside an effect.

Right now our primary use cases are a few collapsible headers that share animation with scrollable views, and changing the title of pages in an animated sequence of steps for walkthrough like scenario (This maybe could be solved with multiple navigation screens maybe). These are currently only used on mobile-sized devices and we have a similar approach to what's described above w/ a shared header on desktop.
I think implementing a Header outside of react-navigation would solve this.

I actually built my own Header component to keep it simple, and I’m only implementing the few props I’m using.

Are you still able to take advantage of the animations from react-navigation?

Right now our primary use cases are a few collapsible headers that share animation with scrollable views

I actually made a mini library called scrollzy that solves this once for react-navigation headers + reanimated scroll animations, but I never publicly released it. Maybe I could repurpose it to work with next too. I'm just not sure if Reanimated's onScroll works on Web (I haven't tried it), but if it does, then it would be easy to implement.
First, you wrap your app in ScrollablesProvider.
Then register your scrollable:
const { onScroll } = useRegisterScrollable()

return <Animated.ScrollView onScroll={onScroll} />

Finally, style based on the scroll position:
const { scrollPosition } = useScrollPosition()

const style = useAnimatedStyle(() => ({
  opacity: withTiming(scrollPosition.value > 50 ? 1 : 0)
}))

You're using this logic on Web too I assume, right?

Are you still able to take advantage of the animations from react-navigation?

No, since this component is Web-only. On Native, I'm still using native stack, though, so there I am. Keep in mind that native behavior is unchanged by my suggestions.
I added some title animations with Moti's AnimatePresence in a few lines on the Web header though.
I implemented this headless navigation approach in my app yesterday and I think it's far cleaner. It's been working really well.

BTW, once Evan Bacon's auto navigation stuff is ready, we can bring Next.js' pages/ folder to native: https://twitter.com/Baconbrix/status/1384383220360171524

I'm mainly using navigation.setOptions to update titles for fetched content or adding buttons that require data only present in that screen. But I agree, all of that can be taken care of on an application level and doesn't have to come from a library.
The main idea here was to preserve that pattern from react-navigation, so we don't make decisions based on platform in those instances.

I'm mainly using navigation.setOptions to update titles for fetched content or adding buttons that require data only present in that screen.

This is a common use-case, but I think that can be solved on Web with getStaticProps, like in the example above.
On Native, I would use a custom headerTitle component that reads the data itself from your cache, rather than calling setOptions on the screen.
If you still need to use setOptions, such as for native stack's large header title, you could do this:
import { NavigationContext } from '@react-navigation/native'
import { useContext, useLayoutEffect } from 'react'

export default function Screen() {
  const maybeNavigation = useContext(NavigationContext)
  const data = useData()

  useLayoutEffect(() => {
    if (data && maybeNavigation) {
      maybeNavigation.setOptions({ title: data.title })
    }
  }, [maybeNavigation, data])
}

I would probably extract that function into use-set-options.ts and use-set-options.web.ts to avoid importing react-navigation on Web and adding to the bundle size.
By importing NavigationContext, rather than useNavigation, we are able to use navigation conditionally and avoid getting an error when there is no NavigationContainer at the root.

Here's one really exciting outcome of not using react-navigation on Web: the top/bottom notches on mobile browsers collapse when you scroll! React Navigation essentially opts you out of window scrolling, which means the notches will never collapse on scroll.
If you need to animate based on scroll position, you can either:

check the window's scroll position on Web, and update your animated value based on that
or, you can wrap your scrollable with a View that has StyleSheet.absoluteFill (or a fixed height).

For a FlatList that needs to fire onEndReached, for instance, you'll need to wrap your view in absolute fill, since otherwise the flat list will never actually scroll. It would probably be better to re-implement something like react-virtual for Web anyway, since FlatList does no virtualization on Web.
In my opinion, this optionality is a big UX boost, and it makes React Native Web apps feel like the best Web apps.

After implementing the more "headless" form of navigation, I'm almost fully convinced this is the way.
Next Router on Web, React Navigation on Native. All navigation is triggered from URLs, with a useRouter() hook and Link/LinkText provided by solito. I'll include docs on how to these links with animations from MotiPressable too, while maintaining browser accessibility.
Since we're using URLs to get around only, you'll need to implement your own linking config. However, you won't need any of the hacks from this PR. Just a normal linking config. On Web,  you won't even import the NavigationContainer (or any code from @react-navigation for that matter.) The pages/ folder will do the work for you.
You'll have full control over your web UI to implement yourself. If you've followed this far, you already have the tools needed to implement this yourself. All that's really left is to 1) release the hooks/components under solito, and 2) document the userland patterns, like headers, back buttons, SEO meta tags, static props, scrolling, shallow page modals, etc.
If you're coming from a Next.js background, you will essentially have to learn nothing new on the Web side. On the native side, you just have to set up your linking config, and then you can organize your stacks/tabs/drawers however you'd like.

How do you currently have types implemented are you using pathpida? We implemented a custom solution; I'm curious if there'd be a way to get some relation between the next pages and the linking configuration so it's harder to mess up the navigation.

Yeah, I'm using pathpida. That would definitely be nice. I've been using pathpida + parseNextPath to extract the actual URL. And the screen names from the linking config also are typed thanks to react navigation's global type declarations.
I really like the Blitz API for codegen'd paths. I asked Brandon if he'd extract them to a separate lib here.
So the only missing piece is the actual URL paths you put in your linking config. For now, I've been using strings, but maybe it could be something like:
import { Routes } from './routes-manifest' // pseudo-code

const linking = {
  config: {
    screens: {
      artistsTab: {
        path: Routes.artists(),
        screens: { artists: Routes.artists() }
      }
    }
  }
}

Where it gets trickier is when you have a pathname that looks like /artists/[slug]. In these cases, I've been using parseNextPath, which turns that into /artists/drake. So for linking config, we could pass :slug as the query param. It would be really cool if we could make a linking config generator that forced you to use string literals if you wrote : at the beginning of your linking config.
But at this point, we're just adding type optimizations on top of react navigation.
So anyway, I'd have something like this for dynamic screens:
import { Routes } from './routes-manifest' // pseudo-code

const linking = {
  config: {
    screens: {
      artistsTab: {
        path: Routes.artists(),
        screens: { artists: Routes.artists(), artist: parseNextPath(Routes.artist({ slug: ':slug' })) }
      }
    }
  }
}

I'm currently doing the above quite often, except that I'm using pathpida instead of the blitz API. Pathpida's API is much uglier, so I won't use it in the example above.
This is my code for parseNextPath, which is used under the hood for solito to fire navigation events on native.
import type { NextRouter } from 'next/router'

const parseNextPath = (from: Parameters<NextRouter['push']>[0]) => {
  let path = (typeof from == 'string' ? from : from.pathname) || ''

  // replace each instance of [key] with the corresponding value from query[key]
  // this ensures we're navigating to the correct URL
  // it currently ignores [...param]
  // but I can't see why you would use this with RN + Next.js
  if (typeof from == 'object' && from.query && typeof from.query == 'object') {
    const query = { ...from.query }
    for (const key in query) {
      if (path.includes(`[${key}]`)) {
        path = path.replace(`[${key}]`, `${query[key] ?? ''}`)
        delete query[key]
      }
    }
    const hasParams = Object.values(query).filter(
      (value) => value != null
    ).length
    if (hasParams) {
      path += '?'
      for (const key in query) {
        if (query[key] != null) {
          path += `${key}=${query[key]}&`
        }
      }
      if (path.endsWith('&')) {
        path = path.slice(0, -1)
      }
    }
  }

  return path
}

export { parseNextPath }

Looks like Evan's auto navigation (now written with Webpack) is also statically adding navigationOptions to screen components inside the pages/ folder. Which means even that part will code share with Web. We're so close to having the best of both worlds.
https://t.co/dqGjOjhzmV

I took two weeks off, had a dream that separating concerns between routers was the answer, then came back to find this. Gotta love it. If you need any help with docs, testing, etc. let me know - happy to pitch in.

I took two weeks off, had a dream that separating concerns between routers was the answer, then came back to find this. Gotta love it. If you need any help with docs, testing, etc. let me know - happy to pitch in.

I've been using it for about a week now and it's really, really great. Feels very future-proof. I'll probably outline next steps soon for getting the community involved.

For those interested, I went on React Native Radio to discuss Expo / Next.js: https://twitter.com/jonesaustindev/status/1484268542325317632

My new library, solito, which will take over expo-next-react-navigation, has started integrating into BeatGig. It's working really well. If anyone wants to try it early, let me know.

As I've integrated Solito into BeatGig, I have slowly solved all of the problems.
While I plan to keep Solito open source, I'm considering making a premium monorepo starter. This way, I can justify spending time on documenting and showcasing the many different patterns and use-cases.
A premium monorepo would be an example app that contains the following (and perhaps more):

authentication
navigation

stacks
tabs

modals
redirects/rewrites
design system setup (or bring-your-own)
recommended monorepo structure
web layouts (like headers, footers, sidebar nav)
animations
setOptions, useIsFocused, etc.

I'm tossing this out here to see if there would be interest. I feel confident in laying out "best practices", but it's a lot of work to put it all into a maintainable monorepo starter.
The paid monorepo's issues/discussions could also be a way for people to share ideas and methods they've used for React Native + Next.js.
I just had the idea for a paid monorepo in the shower, so I haven't thought through all the details. But I think it could be a good way forward.
It would also help me keep it updated with the latest versions (Expo SDK, Next versions, etc) if there is some sort of ongoing subscription payment to it.
Would you be interested in a premium Expo + Next.js monorepo starter? lmk!

@nandorojo Great Idea! Been thinking of doing the same thing for a while, but my monetisation plan would be:

First 20, 50 or 100 sales of the template repo are either free or pay what you want (gets the word out)
Ask those beta testers how many hours this likely helped them save (helps determine sale value)
Price accordingly (e.g. Bedrock by Max Stoiber)
Turn back into "pay what you want" when a hard goal of sales income is reached. (Calculated based on how many hours you've already out into making the template + estimated maintenance cost + any donations you'd like to do to the used techs maintainers, e.g. Evan Bacon, Expo Team, yourself included)

Obviously it's all up to you in the end, but that's my two cents on how I'd try to monetise my own starter template after basically years and years of iteration 🤷♂

So will be this PR updated with Solito?

So will be this PR updated with Solito?

Yes.

@nandorojo What about doing a [sponsor only repository?](https://github.blog/2022-02-02-new-sponsors-only-repositories-custom-amounts-and-more/

Would you be interested in a premium Expo + Next.js monorepo starter?

Would love to support your work if it's not too expensive of a subscription. I think minimum $5/mo, max $10/mo.
-- Poor Guy

@deman4ik I'm figuring out the whole Solito stack (not sure what to call it, but Solito, Dripsy, and Moti. @nandorojo should give the stack a proper name and maybe a GH org) as we speak and will upload a minimal (no bottom sheet, etc...) boilerplate repo very soon. I'm not sure if that helps anyone, but I'll link it anyway since I watched his conf presentation, was super excited, and then thoroughly confused as how to set everything up.

Thanks for that, @corysimmons. Looks like a good boilerplate starter.
There are plans on my end to add full-scale docs (plenty of which are already up at solito.vercel.app 🤫), as well as examples with the many use-cases discussed on this thread.
I'm busy with many work things currently, so my time is constrained. I have ongoing conversations with companies who rely on this stack and may sponsor my work. If I end up doing that, it could speed things up, so I'll try to update here when I know more.
Other interesting concepts could be opening more of a Solito community (Discord, etc.) My GH notifications are already pretty crazy between Moti/Dripsy etc., so I've always been a bit hesitant about adding a Discord that anyone can join. But maybe there is a good way to do that. Perhaps it could come with the (potential) premium example mentioned earlier.
As for reading in params on screens, there is an issue on the solito repo that links to the code for useParam. It's currently just a gist, but this will be part of solito too. I know it feels disorganized, but this code is already running in prod for BeatGig.
I want to get to all of this, you just may have to bare with me a little since I'm busy with work.
Thanks guys! Hope that adds some context for now.

Hey guys. The solito docs are almost ready. I haven't publicly announced it yet, but you can take a look here if you're interested:
solito.dev
Thanks for all the help and suggestions along the way. I'll follow up when I announce solito on Twitter (please wait to tweet it out until then).
It's all coming along!

Solito is released! 🥳 https://twitter.com/FernandoTheRojo/status/1503457235929862154
Please like/retweet that to show support and to get the word out. Solito also has a minimal starter repo now:
npx create-solito-app@latest

I think we're good to close this PR!
@axeldelafosse maybe we should direct people to the solito starter monorepo rather than this monorepo going forward to avoid confusion. Although we may need to port over some of this repo's features first.
Can't wait to see what you all build with solito.

Woohoo! 🥳
Congrats Fernando -- thank you for your hard work and for setting this up properly.

maybe we should direct people to the solito starter monorepo rather than this monorepo going forward to avoid confusion

Yes of course!

Although we may need to port over some of this repo's features first

Which features do you have in mind?

Same features like Drawer, Tab, List-Detail and Modal navigation examples would be great!

As someone who has been visiting this PR religiously since November, thank you so much everyone for your contributions and especially @nandorojo for the inspiration and Solito!!!!

Feel free to send me a message if you are using this stack! We are always looking for feedback.

Maybe an Off-topic message
Hello, I would like to integrate @vercel/commerce with Solito. Do you have some idea how to do that? I am trying to do it but I got errors like this. Cannot find module '@framework/customer/use-customer' or its corresponding type declarations. I believe that is something with the configuration but I couldn't resolve it.

maybe you can open a discussion on Solito, but I would start with a minimal repo using Solito’s starter and adding the least amount of commerce code to show what’s not working there


Workspace connections don't show without added user connection

Azure Data Studio Version: 1.24

Note: Adding a connection to the object explorer shows all connections
Steps to Reproduce:

Have ADS installation with no added connections in Object Explorer
Have ADS Livesite extension installed
Open Livesite Workspace: TSGWorkspace
Notice the servers don't get loaded in the Object Explorer

Below is what I am seeing in the Servers view with the above repro on the current build.  Please verify this issue and close if no repro, or add some additional repro context and assign to me.  Thanks!

Closing as no repro.


Add main chain and tlbc node to bridge docker compose file

Depends on #108

Closed as this belongs to the PoA bridge. We'll create a new task if needed for the new bridge.


Allow Camera?

I have a web app with kiosk enabled.  I would like the user to take a picture.  Is it possible to allow things like a camera to run and return safely without being closed prematurely?
Thanks for an excellent plugin!

Matt

The most simple way can be using HTML5: ;)
https://davidwalsh.name/browser-camera

That is true!  I was thinking about that and I agree would be the best solution for a kiosk mode tablet/phone.   Thanks!  This issue can be closed.

Matt


Interconnected constraints: bodies get stuck oscillating between other bodies

Nice library!
I am just getting started with trying it out for my use case. I am trying to build a visualisation of a graph structure where nodes always have a predecessor and (almost) always connect to another node. The links to connect the nodes need to be drawn at a given distance (can vary from node to node) which is why I tried using Matter.Constraint to simulate links between nodes by specifying the length property.
My goal is to show this as interactive graph with no (link- or node-) overlaps / folds.
Here I have an example codepen which shows my issue. Click on the canvas to add nodes. The first 3 still work nicely and spread well but after that they get stuck between the previous nodes and are oscillating because the bodies are colliding but the length of the constraint is still not satisfied. (Which it could - just not in between the nodes)

This is what I want to see in the case where multiple nodes connect to a center node (it can spread it out nicely after dragging the bodies around):

The graph in my application can and will grow larger than just a few nodes into a center node. So I was hoping defining the constraints would be enough for an autolayout. But since I always have to specify a position for a new node (in my example (0,0) ) mostly it gets drawn directly in between nodes.
I tried already various settings for stiffness and even tried adding bodies between nodes to act like a barrier so that nodes cannot get stuck. But then they still managed to get into that triangular space inbetween sometimes.
Previously I have worked with force graphs. The 'charge force' which makes all nodes repel each other helped with this issue. But there the length of the links where not close enough to the given values.
I'd be very grateful for any hints and suggestions for solving this.
Thanks!

Some suggestions to try:

increase engine.constraintIterations
use a low constraint.stiffness
use more constraints to form a mesh
use a smaller engine timestep and multiple engine updates

and your idea of a repelling force is worth a try I think?


SecretKeyFactoryTests: PBE and PBKDF2 algorithms fixed in FIPS

Fixes for PBE and PBKDF2 algorithms in FIPS mode. For more details see disussion in this JIRA:
https://issues.redhat.com/projects/OPENJDK/issues/OPENJDK-991

looks ok


Keep User Agent (keepua) not working

Hi,
For a particular site, I was recommended by Patrick Meenan to enable the Keep User Agent (keepua) field.
I am testing the site lululemon.co.uk
When doing so, the site works:
https://www.webpagetest.org/result/161128_PM_GRF/
I modified the Bulk Tester spreadsheet so that the scenarios tab and settings tab has the keepua field. I updated the named ranges. However, WPT gives an error as if the keepua field was not enabled.
Any ideas how I can debug?
https://www.webpagetest.org/result/161128_3V_WZD/
Attached are screenshots of the scenarios and settings tab setup with named ranges defined.

This is the WPT URL with keepua=1 querystring attribute that doesn't seem to pass the variable across:
https://www.webpagetest.org/runtest.php?url=http%3A%2F%2Fwww.lululemon.co.uk&k=[KEY HERE]&f=json&location=ec2-eu-west-1%3AChrome&runs=3&video=1&fvonly=0&keepua=1


[master] retrieve user details

Add the user details to the TorusCredentials.
Please review.
Cheers

Thanks for contributing @rodrigopavezi!
One suggestion is to add userInfo to existing TorusCredentials instead of moving key out to TorusKey, the reason is that won't introduce breaking changes, while the current implementation will.
class TorusCredentials {
  final String publicAddress;
  final String privateKey;
  final TorusUserInfo userInfo;

  TorusCredentials(
    this.publicAddress,
    this.privateKey,
    this.userInfo,
  );
}

HI @rodrigopavezi, do you want to proceed with this?
This is a great PR btw!


Initial set of conversion tests

A good starting point for the tests. Still need a few more to get more coverage, but from 0 to 56%.

I think we need to consider a cherry pick PR for 0.1 branch and to do a release for 0.1


[keras/estimator/init.py] Standardise docstring usage of "Default to"

This is one of many PRs. Discussion + request to split into multiple PRs @ #17748

I am not familiar with this part. There are 2 questions to be answered.

Is 2.0 referring TF 2.0? If so, it is already released and the description can be further changed.
yes, the 2.0 here refers to TF 2.0 release.

The file is wrapped in # LINT.IfChange. We may need more changes to pass the test.
The change here should be fine since it only touch the comment/docstring, and not the code.

@qlzh727 may help answer them.

Thanks @qlzh727 for the answer!
Then we need to change the description of the saver completely.
@k-w-w may know what would be the most accurate description here.

Looks like the default was never changed to checkpoint, and at this point probably won't be...
Lets remove the 2.0 part. If we want to roll this out we can always add it back.

Pending on author's change.

Sure thing, made the edit

Sure thing, made the edit. Yeah I noticed that issue when I was going through the codebase and had planned a different issue on this point but happy to merge it all into this one PR.

This is a duplicate for #17957.


Misnamed Icon

Icon fa-folder-open-o is listed under FolderOutlinepenOutline. Note the missing "O" in "Open."

Proposed solution above: Change FolderOutlinepenOutline to FolderOpenOutline to match original FontAwesome naming scheme.


PAL-1077 updated image repository property

Updated image repository value in parent pom

Readers does not build docker images, therefore the image.repository maven value is not required. Can you remove the property rather than updating the value.

Readers does not build docker images, therefore the image.repository maven value is not required. Can you remove the property rather than updating the value.

The property has been removed from the parent pom


step-6: Error: Expected undefined to be '/phones/nexus-s'

In step-6, when running npm run protractor, there is the following error:
Failures:

  1) PhoneCat App Phone list view should render phone specific links
   Message:
     Expected undefined to be '/phones/nexus-s'.
   Stacktrace:
     Error: Expected undefined to be '/phones/nexus-s'.
    at /home/jing/code/tutoral/angular-phonecat/test/e2e/scenarios.js:63:35

The fix is to change expect(url.split('#')[1]).toBe('/phones/nexus-s'); to  expect(url).toBe('/phones/nexus-s');.
Angular version is 1.3.10. I am using a Ubuntu 14.04 box.

Step-7 has similar problems.

Upgrading AngularJS to 1.3.11 solves this problem.

still a problem with 1.3.15
{code}
bower list
bower check-new     Checking for new versions of the project dependencies..
angular-phonecat#0.0.0 /git.repo/angular-phonecat
├── angular#1.3.15 (1.3.16-build.108+sha.fee437f available, latest is 1.4.0-rc.1)
├─┬ angular-animate#1.3.15 extraneous (1.3.16-build.108+sha.fee437f available, latest is 1.4.0-rc.1)
│ └── angular#1.3.15 (latest is 1.4.0-rc.1)
├─┬ angular-mocks#1.3.15 (1.3.16-build.108+sha.fee437f available, latest is 1.4.0-rc.1)
│ └── angular#1.3.15
├─┬ angular-resource#1.3.15 extraneous (1.3.16-build.108+sha.fee437f available, latest is 1.4.0-rc.1)
│ └── angular#1.3.15
├─┬ angular-route#1.3.15 extraneous (1.3.16-build.108+sha.fee437f available, latest is 1.4.0-rc.1)
│ └── angular#1.3.15
├─┬ bootstrap#3.1.1 (latest is 3.3.4)
│ └── jquery#2.1.4
└── jquery#2.1.4
{code}
{code}
/git.repo/angular-phonecat> ./node_modules/.bin/protractor test/protractor-conf.js
Starting selenium standalone server...
[launcher] Running 1 instances of WebDriver
Selenium standalone server started at http://<IP_ADDRESS>:57817/wd/hub
..WARNING - more than one element found for locator By.cssSelector(".phones li a") - the first result will be used
F
Failures:

PhoneCat App Phone list view should render phone specific links
Message:
Expected undefined to be '/phones/nexus-s'.
Stacktrace:
Error: Expected undefined to be '/phones/nexus-s'.
at /git.repo/angular-phonecat/test/e2e/scenarios.js:62:35
at Array.forEach (native)

Finished in 2.673 seconds
3 tests, 6 assertions, 1 failure
Shutting down selenium standalone server.
[launcher] 0 instance(s) of WebDriver still running
[launcher] chrome #1 failed 1 test(s)
[launcher] overall: 1 failed spec(s)
[launcher] Process exited with error code 1
{code}

removed working directory and rechecked out with:
git clone --depth=14 https://github.com/angular/angular-phonecat.git
somehow everything works now for step 6 and 7
I notice that if you leave karma running during: i.e. git checkout -f step-7 it will fail
However if you kill it an rerun everything tests successful.

Still having this problem with 1.3.16

Me too. I'm using AngularJS 1.3.16, need expect(url).toBe('/phones/nexus-s'); fix to pass step-6 e2e test.

I also needed to change it to expect(url) to make it work.

confirming aforementioned: change it to expect(url) works for me too


[WIP] storage: change token fetch to POST request

Try to make compatible with more registries, for example Google Artifact Registry.
Relevant Issue (if applicable)
Details
Try to make compatible with more registries, for example Google Artifact Registry.
Types of changes
What types of changes does your PullRequest introduce? Put an x in all the boxes that apply:

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation Update (if none of the other choices apply)

Checklist
Go over all the following points, and put an x in all the boxes that apply.

[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.

Hello 👋 Great project, really interested in using this in Google Artifact Registry! I am just curious if there is a reason this is still in WIP PR and if it will be picked up? Thank you!

Fixed in master.

@lilic Should be fixed in https://github.com/dragonflyoss/image-service/pull/1425


[bug] it goes beyond its own domain

after playing cybergrind and goign to a normal level, and having calm-combat option in cg on, it still thinks the requirements to play combat is the ones set in cg instead of having any enemy be spawned
to replicate:

launch 4-1 and spawn first enemy batch
see that it plays combat loop
go to cybergrind
3.1) make sure calm loop is enabled for cybergrind
go back to 4-1
spawn first enemy batch
see that its now calm

@surytrap Thanks a lot for the report! It'll be fixed in the next release


Enhance CAPTCHA Speech Recognition to Distinguish Between Capital and Small Letters

Currently, the CAPTCHA in our application does not differentiate between uppercase (capital) and lowercase (small) letters when read aloud using speech recognition. This can make it harder for users to correctly input the CAPTCHA. To improve user experience and accuracy, the speech recognition feature should specify whether each letter in the CAPTCHA is capital or small.
Steps to Implement:
Modify the speakCaptcha function to detect whether each letter in the CAPTCHA is uppercase or lowercase.
If the letter is uppercase, prepend the word "Capital" before reading the letter aloud.
If the letter is lowercase, prepend the word "Small" before reading the letter aloud.
Ensure that numbers and other non-letter characters are read as usual, without any additional description.
Expected Outcome:
When the CAPTCHA is read aloud, users will hear whether each letter is capital or small, making it easier to input the CAPTCHA correctly.
Please assign me this issue under the hacktoberfest 2024 tag

I created a pull request for the same issue. Please do check.


Doxygen Pipeline Still Failing

When I merged CDP 4.0.1 to master, the doxygen.yml workflow still failed with some Access Denied issues:
https://github.com/ClusterDuck-Protocol/ClusterDuck-Protocol/actions/runs/8253841471/job/22576624953
There seems to be several issues here.

It's not finding the docs/html folder which was removed because we don't want to version control the generated HTML files. Not sure why the action is looking for the HTML folder there and not the working directory which is the project root.
The second issue is the access denied to the ClusterDuck github repo.

fixed in #400


Deprecate tls states and configuration

The states in tls.sls file are not being used and tested for a while.
The production Zoomdata setup requires external load-balancer or proxy to efficiently offload TLS, such as AWS ELB, Nginx or HAproxy.
Also,  we do not ship keytool with bundled JVM anymore.

Fixed by #165


Add SampleHeightMostDetailed tileset load failure test

Hmm this is interesting. So in cesium-native, if the tileset can't be sampled at all, we reject the future. Unity tasks have a similar mechanism to future rejection, so that's what we do there, too.
But in Unreal, all we have is an OnHeightsSampled callback, there's no separate error pathway. So instead we call that OnHeightsSampled and indicate that every height failed to sample. As I was doing this, I actually thought that Unreal was the compromise.
I can kind of argue either way, though. The question is: when the tileset is completely broken, and so no height samples will ever succeed, should we report this is "every height sample failed", or should we report it as a more dramatic error? Given that the latter is not possible in Unreal (short of making the user supply a separate error callback), maybe there's value in consistency across game engines.

The more I think about it, the more I like the idea that there's just one error mechanism, rather than two. So I'll switch Native and Unity to work like Unreal, as you suggested.

Ok that's done and this is ready.


Implement ghost- aka. sensor-objects

Objects who report overlaps/collisions with other objects, but don't actually affect them.
Bullet3d calls them ghost-objects; for Box2d and Chipmunk2d, they're sensors.

This isn't the best, but as a workaround you could keep a separate CollisionWorld from ncollide just for handling those overlap queries.

I've been working on this during the past few weeks. I have a first working demo now (not merged with master yet), so hopefully I'll be able to release a first implementation in a week or so!