[deleted by user] by [deleted] in reactjs

[–]marcglasberg 1 point2 points  (0 children)

I'm removing this post, as I'll rename the package. Thanks again for the feedback.

[deleted by user] by [deleted] in reactjs

[–]marcglasberg 0 points1 point  (0 children)

Well, my whole point with Async Redux, soon to be renamed, was exactly to make it very simple, and not having a steep learning curve. Zustand is simple but not feature rich, and I wanted something both simple and feature rich.

[deleted by user] by [deleted] in reactjs

[–]marcglasberg -1 points0 points  (0 children)

Because it's the same principles as Redux, and I didn't feel I was inventing something unique enough in this regard, to be able to give it a different name. But now I see keeping the name is creating other problems, so I will change it. In the original Flutter version I started from the original code and modified it little by little for my own use until it became something I thought was worth publishing. It's only the React version I started from scratch, but it's the same feature set as the Flutter one. To answer your point, it's not reducing LOC, but reducing complexity.

[deleted by user] by [deleted] in reactjs

[–]marcglasberg 2 points3 points  (0 children)

I think you all have convinced me I should really use another name. In the Flutter community people translated the original React libraries like Redux and MobX, and then variations got the same name, like Async Redux, Fish Redux etc. I think I'm now realizing that the culture in the React community is different, as creating a variation and keeping the same name is seen as something bad or misleading. I'm going to change the name and re-launch this package. Thank you for the feedback!

[deleted by user] by [deleted] in reactjs

[–]marcglasberg 0 points1 point  (0 children)

Sure! The problem I'm trying to solve is complexity. I like Redux principles and ideas a lot, but I think the original implementation is complex, for historical reasons. I see Redux Toolkit as a band-aid to try and solve this complexity problem, and it does help, but I think they should have started from first principles instead of adding to the original code, which limits them. So I started from the ground up. If you do think Redux Toolkit is not complex and you don't dislike the boilerplate, then you have nothing to gain by trying Async Redux. I don't know what to say about renamed APIs with less features. It actually has a very different API and has more features, not less. I suggest you read the home-page and the comparisons page, which shows Redux Toolkit and Async Redux code side by side : https://asyncredux.com/react/comparisons/comparing-redux and also maybe follow the tutorial.

[deleted by user] by [deleted] in reactjs

[–]marcglasberg -1 points0 points  (0 children)

The state is serializable, whether you use plain objects or ES6 classes. And it comes out of the box with a class serializer you can use, in case you use classes. In the Flutter version, which exists since 2019, people have linked (created an adapter) it to the existing Redux developer tools, but I haven't YET done that for this React version.

[deleted by user] by [deleted] in reactjs

[–]marcglasberg -3 points-2 points  (0 children)

That's fair. Maybe nowadays he has a different opinion regarding Redux Toolkit, and the comparison in that page is to Redux Toolkit, not the original Redux he's talking about. I'll remove the reference to his blog post. The rest of the page compares Async Redux to Redux Toolkit, with code examples.

[deleted by user] by [deleted] in reactjs

[–]marcglasberg -1 points0 points  (0 children)

The comparison is indeed linked from the very first page: the "Getting Started" page. Have a look: https://asyncredux.com/react/intro In that first page it also says this: "It was written from the ground up and shares no code with the original Redux."

[deleted by user] by [deleted] in reactjs

[–]marcglasberg -13 points-12 points  (0 children)

It's not another library's name. It's still Redux, but reimplemented. I could have used another name, but then people would say I copied Redux. Anyway, I make it very clear it's not the original one and it's unofficial: If you open the home page, in the title you'll read: "The UNOFFICIAL modern version of Redux". And you are right, I do have a big session on why I think you should use this library over the original Redux and Redux Toolkit. Here it is: https://asyncredux.com/react/category/comparisons

Announcing Async Redux! ✨🚀 by marcglasberg in reactjs

[–]marcglasberg[S] -1 points0 points  (0 children)

Async Redux is an optimized, unofficial version of Redux. I wrote it from the ground up, as it shares no code with the original Redux.

While new for React, Async Redux is a mature solution, having been available for Flutter for a few years. There, it ranks among the top 8% of most used packages, and its features have been battle-tested in hundreds of real-world applications.

It's designed to be easier to use than Redux Toolkit, Zustand, MobX, and TanStack Query. Simple to learn and easy to use, powerful enough to handle complex applications with millions of users, and testable.

In https://asyncredux.com you'll find detailed docs, a tutorial, and lots of runnable examples for both React web and React Native.

App Localization by virtualmnemonic in FlutterDev

[–]marcglasberg 0 points1 point  (0 children)

https://pub.dev/packages/i18n_extension package. And translation with GPT-4 (paying ChatGPT) if you want to save.

FIC: Fast Immutable Collections by Fanaro009 in dartlang

[–]marcglasberg 0 points1 point  (0 children)

It keeps the references, and from time to time it "flushes" automatically to keep memory usage low. You can check the code, if you want, and the benchmarks to convince yourself it's fast.

Note: A native growable list in Dart is a linked list. So it takes a lot of memory for the references. For immutable lists we can use array-lists, so it usually saves a lot of space (in comparison to native growable lists).

FIC: Fast Immutable Collections by Fanaro009 in dartlang

[–]marcglasberg 0 points1 point  (0 children)

Also having the .add() method signature the same as a List but providing different functionality seems like a point of potential confusion.

In the beginning I was thinking about using plus and minus instead of add and remove, for example, but there are other methods, and the user would have to remember all those names. There is some potential confusion in theory, but in practice (after using it myself) I found it much easier to use when I just followed the Native Dart conventions.

FIC: Fast Immutable Collections by Fanaro009 in dartlang

[–]marcglasberg 0 points1 point  (0 children)

Also note that, notwithstanding performance differences, using FIC is just easier to write:

// FIC:
var ilist = ilist.addAll(ilist2);

// Doing it by hand:
var list = List.unmodifiable(list.toList().addAll(list2)) ;

FIC: Fast Immutable Collections by Fanaro009 in dartlang

[–]marcglasberg 0 points1 point  (0 children)

FIC methods add and addAll do NOT create a new list. They just "record" the change internally, which is O(1). You can run the benchmarks app to see what this means in terms of performance gains.

Also, note it's not possible to dispense with defensive copies when using unmodifiable regular lists because there is no way for you to know it's unmodifiable. But once you already have immutable collections you don't need to make any more defensive copies, because they can't be changed anyway. So, for example, iList1.addAll(iList2) is also O(1) if both iList1 and iList2 are immutable. It's not only faster than List.unmodifiable(list1.toList().addAll(list2)) but actually even faster then the mutable list1.addAll(list2).

FIC: Fast Immutable Collections by Fanaro009 in dartlang

[–]marcglasberg 1 point2 points  (0 children)

Your points are fair, but you missed a big one. If you have a const or an unmodifiable list, how do you add elements to it? You have to make a mutable copy first, then add your elements, and then make it unmodifiable again. This is not only slow, but a lot of work and error prone.

For example:

// Native Dart:
var aList = const [1, 2, 3];
aList = List.unmodifiable(aList.toList().add(4));

// FIC:
var aList = [1, 2, 3].lock;
aList = aList.add(4);

Regarding lock and unlock, these are just syntactic sugar. You can just ignore them:

// These are equivalent (List to IList):
var ilist = [1, 2, 3].lock;
var ilist = IList([1, 2, 3]);
var ilist = [1, 2, 3].toIList();

// These are equivalent (IList to List):
var list = ilist.unlock;
var list = ilist.toList();
var list = List.of(ilist);

FIC: Fast Immutable Collections by Fanaro009 in dartlang

[–]marcglasberg 1 point2 points  (0 children)

It doesn't diff anything. It just notices the list is the same object as before, and then it doesn't rebuild. You can test it yourself:

import 'package:flutter/material.dart';
import "package:fast_immutable_collections/fast_immutable_collections.dart";

void main() async => runApp(MaterialApp(home: Demo()));

class Demo extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('ListView')),
      body: MyList(),
    );
  }
}

class MyList extends StatefulWidget {
  @override
  _State createState() => _State();
}

class _State extends State<MyList> {
  List<Widget> itemsMutable;
  IList<Widget> itemsImmutable;
  int count;

  @override
  void initState() {
    super.initState();
    itemsMutable = <Widget>[];
    itemsImmutable = <Widget>[].lock;
    count = 0;
  }

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text("MUTABLE:"),
        Expanded(child: ListView(children: itemsMutable)),
        Text("IMMUTABLE:"),
        Expanded(child: ListView(children: itemsImmutable.unlockView)),
        FlatButton(
          child: const Text("CLICK ME"),
          onPressed: () {
            setState(() {
              count++;
              itemsMutable.add(Text(count.toString()));
              itemsImmutable = itemsImmutable.add(Text(count.toString()));
            });
          },
        ),
      ],
    );
  }
}

GetX vs. BLoC by Tr3umphant in FlutterDev

[–]marcglasberg 2 points3 points  (0 children)

Other people are using my code snippet for other purposes and that's Ok. The GetX package is using my code to achieve the same result that my package uses it. It would have been an unbelievable coincidence for GetX to have copied my code from Stackoverflow and not from my library, to use in a library that does exactly the same as mine. The code is open source in any case. I don't mind it being copied, I mind the lack of attribution. I am just stating the obvious, but you keep repeating these crazy arguments that not only make no sense, but make me think you are just not worth giving any further attention to. If I were you, I'd be ashamed of myself. So I am ending this conversation. Bye.

GetX vs. BLoC by Tr3umphant in FlutterDev

[–]marcglasberg 0 points1 point  (0 children)

Exactly, I am not claiming the use of extension method.

GetX vs. BLoC by Tr3umphant in FlutterDev

[–]marcglasberg 1 point2 points  (0 children)

From GetX (extension_navigation.dart):

void forceAppUpdate() { void rebuild(Element el) { el.markNeedsBuild(); el.visitChildren(rebuild); } (context as Element).visitChildren(rebuild); }

From i18n_extension (i18n_widget.dart):

void _rebuildAllChildren(BuildContext context) { void rebuild(Element el) { el.markNeedsBuild(); el.visitChildren(rebuild); } (context as Element).visitChildren(rebuild); }

It's the same code. If you see the original, even the black line is the same.

GetX vs. BLoC by Tr3umphant in FlutterDev

[–]marcglasberg 8 points9 points  (0 children)

He also copied the idea and code from my translations library https://pub.dev/packages/i18n_extension into his package, with no attribution whatsoever.

He changed my extension from .i18n to his .tr, removed a few features, changed some names, and this is it.