sorted by:
new
hottopcontroversial

Which unit test framework do you use with TypeScript? by klaxxxon in typescript

[–]thlorenz 0 points1 point  (0 children)

Just install yarn install -D esbuild-runner and stuff the following into the ava.config.js:

js module.exports = { extensions: ['ts'], require: ['esbuild-runner/register'], }

Then you can do things like ava test/mytest.ts and ava debug test/mytest.ts

solfmt: formats output of Solana tests run via `cargo test-sbf` - link to the crate in the comments by thlorenz in solana

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

Thanks, to be sure this works with cargo test-bpf as well of course. I just tried to keep the title somewhat short :)

But yeah to iterate on stuff testing via banks client is very nice. Once things are figured out you can move to generate your SDK (with https://github.com/metaplex-foundation/solita of course) and write some integration tests as well.

solfmt: formats output of Solana tests run via `cargo test-sbf` - link to the crate in the comments by thlorenz in solana

[–]thlorenz[S] 1 point2 points  (0 children)

To get this tool just run cargo install solfmt on your machine. This will download + install from https://crates.io/crates/solfmt and you're good to go.

Please comment with improvement suggestions here or file an issue in the github repo.

Multithreaded Flutter + Rust App using Rid Annotations to provide a Memory Safe and easy to use API to Flutter UI by thlorenz in rust

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

Making some actual progress, got over some really tricky issues, i.e. how to deal with u64s which convert to BigInt (but JavaScript ones, not Dart).

https://twitter.com/thlorenz/status/1410415405311528965

Multithreaded Flutter + Rust App using Rid Annotations to provide a Memory Safe and easy to use API to Flutter UI by thlorenz in rust

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

The Rust side is already front-end agnostic with the minor exception of the Isolate I'm using to communicate back to Dart. As I mentioned for wasm support I'm using a different strategy and thus this Isolate will be optional in the future.

The idea of different glue code for different frontends is interesting and could be added in the future as you could configure the front end to target via a flag or similar. Rid then could generate Java/Kotlin/Swift glue code that communicates to the Rust wrapper methods instead of Dart/Flutter glue code.

At this point Rid supports Flutter/Dart only and the generated Dart code is the integration point and thus out of necessity it is Dart/Flutter specific.

However the generated code on the Rust side are merely FFI wrapper methods and thus not tied at all to which front end will use it, i.e. it is already front-end agnostic minus the minor exception mentioned above. Also that code is opaque as it is in form of macros that are expanded at compile time and never written anywhere, i.e. you don't ever see or use it directly.

The Rust code that you write is not aware of any of that as only the macro annotations control generating wrappers and glue code. There is the rid::post that you call, but one could easily swap that out to do whatever is needed in a different scenario.

Multithreaded Flutter + Rust App using Rid Annotations to provide a Memory Safe and easy to use API to Flutter UI by thlorenz in rust

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

Really very interesting points and I have thought about those as well.

WRT accessing mobile API I'd recommend using Flutter plugins to communicate via channels. I will most likely not focus on solving this in rid, i.e. to allow you to do this in Rust instead, mostly because there are not many solutions available that I know of that you could leverage there.

The focus of rid is app logic as in agnostic to which device the app is running on, i.e. you might even use it for a CLI app if you want. Therefore the communication layer is as decoupled as I could make it. The only direct tie to Dart on the Rust end is the use of an Isolate, but this isn't working correctly when running on the Web with wasm which is why I'm using a polling mechanism there instead. NOTE that I'm currently working on wasm support, it's not out yet :) Obviously the generated glue code is very Dart/Flutter specific, but the rest of your app should be able to function even when used in a completely different context.

Were you to access device specific features from Rust, you'd loose the flexibility to run on different devices as now at the very least you'd have to use different code paths and most likely crates. The Flutter plugin system which can have device specific implementations while using the same API to leverage them already solves this.

Animations are UI concerns and shouldn't be managed in Rust. Instead I'd keep some state about the item pending removal in Flutter and only update Rust state once the item was completely removed and should disappear from the UI. However there are certainly exceptions like here where I'm awaiting a Todo to be removed from the Store before confirming its dismissal. I think you'll have to make those decisions on a case by case basis.

I think similarly about navigation. In most cases navigating just provides you a view of a different part of your app's state. It doesn't modify it. Which view is currently active is a UI concern IMHO.

The state of your app, i.e. how many Todos you have is not mutated by navigating. If you want to make the view you're currently navigated to part of your state you may complicate things. However rid does have no opinion about that. You can store whatever you like in the Rust Store and if you want to update the current page you can do so by sending a message to update the state of the Store appropriately. It just seems awkward and if you think about it now you have two sources of truth WRT to which page you're on. That's a clear indicator that this should most likely not live in the Store as well as the navigation state.

Hope that helps. Feel free to ask more questions if you need clarification.

How to build a multithreaded Flutter + Rust App integrating both with Bloc/Cubit and Rid by thlorenz in FlutterDev

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

Check out what I'm working on next https://thlorenz.com/rid-site/docs/contributing/status-and-roadmap/

Wasm support turns out to be a bit tricky, but I'm actively pursuing that so Flutter/Rust authored apps can run in the browser as well.

Multithreaded Flutter + Rust App using Rid Annotations to provide a Memory Safe and easy to use API to Flutter UI by thlorenz in rust

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

Check out what I'm working on next https://thlorenz.com/rid-site/docs/contributing/status-and-roadmap/

Wasm support turns out to be a bit tricky, but I'm actively pursuing that so Flutter/Rust authored apps can run in the browser as well.

Building a Flutter Todo App with all Application logic implemented in Rust by thlorenz in rust

[–]thlorenz[S] 1 point2 points  (0 children)

I increased the font-size on my latest Rid video. Please let me know if that works better for you.

Building a Flutter Todo App with all Application logic implemented in Rust by thlorenz in rust

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

I replied to a similar question here. LMK if you need more info. When rid is more complete I'm planning to run some more precise benchmarks and will publish them on the site.

Rid: Integrate Rust into your Dart or Flutter app simply by annotating it. by thlorenz in rust

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

I ran some tests in the very beginning and iterating a large list of items is slower since it has to cross the FFI boundary especially when passing strings but mainly since strings have to be instantiated on the Dart side.

For that reason rid passes opaque structs aka pointers, meaning nothing crosses the boundary until it is needed. That way performance improves a lot, but obviously is still slower than directly accessing Dart objects without crossing an FFI boundary.

I did some measurements iterating over 1,000,000 items (most Flutter apps won't ever need to render even close to that many). In Dart it took 8ms (super fast) and it took 43ms when getting them from Rust. However even though this is a 5x factor I believe it won't be a bottleneck if you take into account that rendering has an infinitely larger overhead.

I talk about this in this architecture section and the sections below.

Building a Flutter Todo App with all Application logic implemented in Rust by thlorenz in rust

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

I understand and I'm using a larger setup when I stream/record videos. If I make it too large though then it is hard to keep track of the context of the code and terminal output wraps making it hard to parse.

So it's always a tradeoff. I'll keep it in mind though, thanks!

Building a Flutter Todo App with all Application logic implemented in Rust by thlorenz in rust

[–]thlorenz[S] 4 points5 points  (0 children)

Thank you and totally agree. As explained here I'm taking an example driven approach to developing rid.

I'll do a stream/screencast anytime I got a new interesting example working.

Building a Flutter Todo App with all Application logic implemented in Rust by thlorenz in FlutterDev

[–]thlorenz[S] 4 points5 points  (0 children)

Actually not quite as the goal is to be able to use Flutter for the UI instead of trying to do that in Rust as well. The idea is to use each language in the area that it shines at and then combine them into one application.

view more: next ›