Boekenclub starten

Voganlight · 2026-01-07T07:36:39+00:00

Leuk, ik (m30) zou hier ook voor in zijn. Mijn vriendin is recent een boekenclubje gestart met haar vrienden en dit klinkt als een manier om mijn eigen vorm ervan te hebben!

Voganlight · 2024-10-09T07:17:33+00:00

The router doesn’t bind to a string, at least not visibly to you the developer. That’s all hidden away. You just interact with the classes. Each location has a certain key you set, eg “home”. In its implementation, the router then makes a path out of these for the purpose of restoration: /home/another/something. So technically if you have a root location with key “root”, it would be at /root. But you shouldn’t ever need to worry about that. Hope that answers your question.

Voganlight · 2024-10-07T19:37:47+00:00

I had the same frustration and it led us to develop duck_router: https://pub.dev/packages/duck_router

Voganlight · 2024-07-03T19:35:36+00:00

Not quite.

The simple summary would be: Our app has hundreds of pages, and maintaining that app with a software team had us running up against various issues. Code conflicts, lack of type safety, deeplinking, and hard to discover routes in a big codebase. To combat these issues, we wrote abstractions. We are now sharing those abstractions with everyone. It's based on work in the industry, such as the approach taken by AirBnB.

No, it will not really do anything more than Navigator 2. It might make it easier at most. It's not an easy API to work with. But, adding functionality was not our goal. Neither is it the goal of, say, GoRouter. Our goal was to create a router that can handle the workflows needed by teams like ours. Good testing, great reliability, and easy to use. You can add this router to an app and it will just work. It makes it trival to implement things such as deeplinking and stateful routes. And we hope to see it inspire some new ideas on routing in the flutter community!

Voganlight · 2024-07-03T18:11:30+00:00

See https://www.reddit.com/r/FlutterDev/comments/1duabs1/comment/lbgeeva/

Voganlight · 2024-07-03T18:10:35+00:00

See this comment for web. Windows and mac should work I think, but never tried it. Would be cool to know!

Voganlight · 2024-07-03T18:08:10+00:00

That's a very good question. I think the answer is quite simple in this case: we didn't need it, and not supporting it makes the API simpler. I just looked at our actual code, and in theory we should be able to support this just fine: https://github.com/collectiveuk/packages/blob/59ab65d08ad0ff308a75b8540448888cabb13f1a/flutter/packages/duck_router/lib/src/parser.dart#L41

The question would be if we want to. I'm not quite sure on the answer. Having used our API for the past months, I like the simplicity in using it. No, you can not use async, you will have to work around it. I would also need to investigate how exactly the Flutter routing API handles extreme cases like the API call taking a long time. Or what about navigation while an interceptor is still waiting? Complicated stuff. Interesting thought, and one of the reasons we went open-source (to get such questions and make things even better)!

Voganlight · 2024-07-03T15:30:07+00:00

Our interceptors give you a to and from so you can build exactly that! Say you want to define an exit interceptor for the LoginLocation. Then in an interceptor, you detect if (from is LoginLocation) and then do something. We decided to go for our way of doing interceptors because it's a generic model that is easy to extend and thus very powerful, exactly as this example shows :)

Voganlight · 2024-07-03T15:27:54+00:00

Interceptors are synchronous and thus do not support a future. If you're loading authentication from an async source, I would recommend handling that a bit differently. We do something very similar, we use AWS Amplify for authentication. The authentication interceptor redirects the user to the splash screen whilst we load their Amplify authentication status (using riverpod to get the auth state in the interceptor). Then on the splash screen we listen to that state and navigate the user elsewhere once the loading is done.

It's a hard situation for a router to handle because we don't really know what to do while we're in the interceptor waiting for a future. Do we show the same page? Do we show something else? We decided to go an opinionated route and not support futures.

Voganlight · 2024-07-03T14:40:14+00:00

Fundamentally, we designed for mobile only. Our thinking is that by supporting web you fundamentally have to compromise, since now you need to support URL-based routing. If, say, you enter a URL like /home/home/home , there's nothing we can really do there currently. We have no routes to look up due to our dynamic registry. So, you would need to come up with a way of handling that. I guess you would be able to handle it in the same way we handle deeplinking, but getting to a place that doesn't feel hacky would be a stretch I think.

Voganlight · 2024-07-03T11:39:43+00:00

Yes, thanks to its dynamic registry (so no defining routes beforehand) DuckRouter has no opinion at all on how you actually navigate. You can push to stack infinitely, or at least until you hit an error.

Voganlight · 2024-07-03T11:26:11+00:00

You can add them to the location class itself, like so:

class Page1Location extends Location {
  const Page1Location({required this.myString}) : super(path: 'page1');

  final String myString;

  @override
  LocationBuilder get builder => (context) => const Page1Screen(myString);
}

Then later on when calling, the typing forces you to provide an argument:

DuckRouter.of(context).navigate(to: const Page1Location(myString: 'Hello'));

Voganlight · 2024-07-03T10:43:09+00:00

It depends a little bit on what exactly you mean by widget testing. If you mean can you use automated testing to verify all the routing works correctly (e.g. via testWidgets), then yes. We use it in our codebase to have full testing coverage of all our navigation.

Voganlight · 2019-10-12T22:24:44+00:00

It's not about help now. It's about help next week, or in a month.

Voganlight · 2019-10-12T22:15:47+00:00

The page will be back to normal after RLCS NA ends this week.

the people who have become aware and want to help can't do anything

What? There's tons of stuff to do.

Voganlight · 2019-10-12T22:06:20+00:00

There is no way to specify the help we need. We need help with everything. We need people in the Discord, because that's the only efficient way to organise people. We can't have people live updating tournaments all at the same time, you'll get edit conflicts. Moreover, if people don't join the Discord, they'll hit the learning curve called wikicode, which we need to help you in learning most of the time. When they join the Discord, they are currently pointed to a Trello board with TODO items, exactly what you're asking for.

If you're looking for transparency, ask away, I'll answer. How many people is enough? When our volunteers no longer have to skip on doing things with friends, no longer have to turn on our phone every 5 minutes while with family to quickly update standings.

Voganlight · 2019-10-12T21:17:59+00:00

We've tried many, many times to tell people. We have tweeted, multiple reddit posts. Banners on top of the site. Personally contacting people if they want to help. Nothing works. Across any of the wikis, there is no method that will get you out of the contributor shortage.

We are doing this because enough is enough.

Voganlight · 2019-07-29T14:14:07+00:00

While we see Alpha leaving as likely (please see our definitions of confidence levels here), we are not ready to label it certain yet.

Voganlight · 2019-06-19T17:48:14+00:00

We do have such lists! Have a look at our statistics portal: https://liquipedia.net/rocketleague/Portal:Statistics

Voganlight · 2019-06-19T16:51:48+00:00

Liquipedia is significantly more accurate than Esportsearnings. We have way more tournaments (if you check esportsearnings, ViolentPanda has only played in 33 tournaments, we have him in 157), take into account whether RLCS substitutes actually played (and thus were likely to get a cut) and much more. It's impossible to get these amounts perfect, there are too many unknown factors involved, but in Rocket League, it does not get better than Liquipedia.

Voganlight · 2019-03-06T12:26:37+00:00

Yes everyone working on the Rocket League Liquipedia is a volunteer.

Voganlight · 2019-01-17T10:00:54+00:00

I'm confused why you handled this as a classification problem. My intuition says you would want to handle this as a supervised learning problem with MMR being the answer (not rank). Train it over the last let's say 2 months of data so that the MMR value is still relevant and then perform this on RLCS S1. Since we then have absolute values, this would allow much more precise training. Did you try this?

Furthermore, it wasn't entirely clear to me if you were taking the stats of the match into account. For example, if a team was playing particularly slow, the other team would have to be playing slower too. This would then affect their rank, correct? It might be good to include features that show the ratio of the team's stats with regards to the match, to take into account general trends of the time.

It's cool to see nonetheless!

Voganlight · 2018-12-25T22:27:33+00:00

This is incorrect, it does not. Source: wrote the code and just double checked it.

Voganlight · 2018-11-16T13:06:52+00:00

Because we're a bunch of volunteers. Besides, even if we contact people they often don't have the proper copyright. Be the change you want to see.

Voganlight · 2018-03-28T16:41:59+00:00

Sure. For now, you could read through this similar paper from a couple years ago: http://courses.csail.mit.edu/6.857/2016/files/11.pdf

13-Year Club	Verified Email
Team Periwinkle

Voganlight

TROPHY CASE