Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Edouard Coissy
    @geekrumper
    name: my_over_react
    description: An absolute bare-bones web app.
    
    environment:
      sdk: '>=2.0.0-dev.55.0 <2.0.0'
    
    dependencies:
      over_react: ^1.25.0
    
    dev_dependencies:
      build_runner: ^0.8.7
      build_web_compilers: ^0.4.0
    
    transformers:
      - over_react
      - $dart2js
    Aaron Lademann
    @aaronlademann-wf

    @geekrumper currently no. We have made some progress towards it in the https://github.com/Workiva/over_react/tree/2.0.0-dev branch, but the big hurdle is removing the over_react transformer altogether. (Dart 2.0.0 does not support transformers)

    We are actively working on that - and it will require some slight boilerplate changes with how components are built. There will be extensive release notes / migration guide content once we release a Dart 2.0 compatible version.

    Edouard Coissy
    @geekrumper
    oh... too sad, I do not intend having multiple dart sdks on my computer :(
    everyone is searching for a library that solves webdev like flutter(react) and this would be the closest one
    Aaron Lademann
    @aaronlademann-wf
    @geekrumper switching between two different versions of dart is pretty simple using brew. For example... if you have Dart 2 and also Dart 1.24.3 installed using brew... you can just say brew switch dart 2.0.0 / brew switch dart 1.24.3.
    Also... Workiva has hundreds of thousands of lines of over_react code in use in production code - so I assure you, Dart 2 support is on a very near horizon.
    Edouard Coissy
    @geekrumper
    sounds great, I just don't have brew and to have it only for switching between dart sdks... I guess you have more than that reason to use it, have you?
    okay, I'll wait if it's coming soon
    @aaronlademann-wf thanks for the great information and fast reply though
    Aaron Lademann
    @aaronlademann-wf
    Brew? Its the recommended way to install Dart: https://webdev.dartlang.org/tools/sdk#install
    Edouard Coissy
    @geekrumper
    yeah, I choose the alternative way with the executable
    Gary Becks
    @g5becks
    @aaronlademann-wf any updates on the dart 2 support?
    Also, last 5 versions of the api docs on the site is failing
    Aaron Lademann
    @aaronlademann-wf

    @Gee5ive the API docs failing is an unfortunate by-product of the Dart team's decision to effectively cease support for many aspects of the Dart 1.x package ecosystem. OverReact depends on Dart's analyzer package - and our current version constraint on that package makes it so that the pub get command fails when the pub.dartlang.org service attempts to build the docs. That will be resolved once we are Dart 2 compatible, which I expect to happen in the next month or so. I don't have a firm date, but I can tell you that there is a team of engineers at Workiva that are completely focused on making OverReact compatible with Dart 2, and they are actively developing / working on that every day. One of our key milestones for adding Dart 2 support to OverReact was reached on October 19th when react-dart 4.5.0 was released: https://github.com/cleandart/react-dart/releases/tag/4.5.0

    Thanks for your patience!

    Gary Becks
    @g5becks
    @aaronlademann-wf that sounds great. Good to hear. Thanks.
    Sung-Chul Lee
    @sclee15
    Is over react ready for dart 2?
    Aaron Lademann
    @aaronlademann-wf
    Aaron Lademann
    @aaronlademann-wf

    @geekrumper @Gee5ive @sclee15 over_react 2.0.0 has been released, making it compatible with Dart 2!

    https://pub.dartlang.org/packages/over_react/versions/2.0.0

    Be sure to read the Dart 2 migration guide as well: https://github.com/Workiva/over_react/blob/master/doc/dart2_migration.md

    Stefano Rodriguez
    @sroddy
    @aaronlademann-wf amazing news! I’m going to give a try to this framework soon but I’m trying to figure out how to deal with a couple of key issues
    1) Routing: what is your suggested approach?
    Stefano Rodriguez
    @sroddy
    2) Animations: is there a simple way to deal with the standard element enter/leave animations
    3) Third-Party libraries: is there a way to use other react libraries written in js? For example if I want to use one of the carousel libraries already available for react?
    Stefano Rodriguez
    @sroddy
    4) Native DOM: is there a way to access and manipulate the DOM elements using dart html for the lifecycle of the component?
    Aaron Lademann
    @aaronlademann-wf
    @sroddy
    1. A router is more of an application level concern, not a react framework one. You could write a Dart=>JS interop layer around a JS library like react router, or try to find a dart SPA router package and roll with that. Neither option would be easier / harder to use with over_react since it is just a strongly typed version of the React JS framework, written in Dart.
    2. Not sure what you mean by "standard element enter/leave" animations, but over_react doesn't do anything special that would make solving that issue any different than it would be if you were just using React JS. Remember, over_react is just a strongly typed version of the React JS framework, written in Dart. Anything that you can do in React JS, you can do in over_react... its just Dart.
    3. There are two options if you want to use other React JS libs. You can write a Dart=>JS interop layer around the JS library, or you can rewrite the library in Dart.
    4. The entire idea of React JS is that it handles all Dom mutations via the lifecycle. Mutating Dom directly by accessing the node within a React component is not something I would recommend. However - if you just need to use the Dom node in a "read only" way, you can use the findDomNode function: https://pub.dartlang.org/documentation/over_react/latest/over_react.react_wrappers/findDomNode.html
    Stefano Rodriguez
    @sroddy
    1) Sounds good. In general I was looking more for a recommendation, as you have more experience for sure :)
    2) something like this (that was once part of the standar react library) https://github.com/reactjs/react-transition-group
    3) OK, I will play a bit with that.
    4) I was thinking about something like what's explained here (although not recommended sometimes it's useful): https://medium.com/@garrettmac/reactjs-how-to-safely-manipulate-the-dom-when-reactjs-cant-the-right-way-8a20928e8a6
    Sung-Chul Lee
    @sclee15
    It is good to know that over react is now working on Dart 2
    Thank you for maintaining this repo.
    Dustin Graham
    @dustin-graham
    Hi everyone. I've been building a Flutter app for the past year full time and my company also builds a standard ReactJS app as well. we're going to be implementing some of the same features in our web app as we already have in mobile. I'm interested in investigating whether my existing Dart code could be used with out existing ReactJS app in-place using this library. Or does it not work that way?
    Aaron Lademann
    @aaronlademann-wf

    @dustin-graham over_react is a library that provides base classes to make it easier to build strongly-typed React UI component definitions, and to consume them using a "fluent" syntax similar to JSX. It wraps around the react-dart library - which is a JS-interop layer atop React JS.

    I may be misunderstanding your question... but my gut says - no... since at the end of the day - over_react is still a "React JS"-based library, and isn't designed for use with Flutter at this time. It may, however - be a relatively simple transition for you to "map" your Flutter widgets into over_react component definitions since there is quite a bit of overlap between Flutter patterns and React patterns - particularly as it pertains to component "lifecycle".

    Jami Couch
    @fbcouch
    hey guys, i've been experimenting with changing the factory generators to be more flutter-like when you're using them; so instead of (MyFactory()..myProp = 'value')(list of children) you would do something like MyFactory(myProp: 'value', children: [list of children],)...is there an underlying advantage to using the first way over the second?
    Keal Jones
    @kealjones-wk

    Hello Jami, sorry for late reply, the second way could probably be achieved fairly easily with some modifications to the generated code but ill list a few reason i believe that the "fluent" style may be better, take all these reasons with a grain of salt though, i am only a year in on the over_react team and i haven't utilized flutter or flutter for web very extensively yet, and there honestly probably are OTHER ways flutter may handle these situations.

    1. The flutter method is achieved using name constructor arguments whereas the over_react pattern is using field setters and getter on a class, meaning that over_react has the ability to not only use custom logic in a getter/setter for that field to handle it differently, where to achieve the same effect with a constructor named arg you would have to add all the logic into the constructor. Also because its an Instance field it doesn't need to re-construct the class to update (DISCLAIMER: I am very unsure of how any of this works in flutter actually so that last re-construct idea could be way wrong).

    2. We could possibly open up the ability to do something like (MyFactory()..children = [list of kids])() but this would probably get a little sketchy if someone were to do (MyFactory()..children = [list of kids])([different list of kids]). because in this case what would be the expected output, sure we could merge them but which do we put first? additionally the current over_react pattern for children allows for what we call "variadic" children, meaning you are not required to pass a List for children, which removes additional characters and make the code easier to read, IMO, for example:

       Dom.div()(
           Dom.button()('click me'),
           Dom.br()(),
           Dom.code()('hi'),
       )
    3. Because UiProps (UiFactory is a UiProps with a componentFactory) implements a Map like interface so we get the added advantage of "prop forwarding". Meaning we can use ..addProps(copyUnconsumedProps()) or even other simple methods that Maps get out of the box without needing to write special logic or props for each component to handle that case, giving it more flexibility.

    Elvis Lee
    @Elvis5566
    Hi guys,
    I got an Exception: "react.js and react_dom.js must be loaded" if I use build_web_compilers version 2.1.1. (The same version in over_react's pubspec.yaml)
    The same issue is gone if I switch to v1.2.2.
    Can you help me out? thank you.
    Elvis Lee
    @Elvis5566
    It seems like there is something to do with dart version. The issue is gone if I upgrade to dart 2.4. thanks anyway.
    Aaron Lademann
    @aaronlademann-wf
    @Elvis5566 ah. We'll get a patch release out that bumps the lower bound of the Dart SDK requirement to ^2.4.0. Thanks for reporting this.
    Aaron Lademann
    @aaronlademann-wf
    David Doty
    @dave-doty
    image.png
    As suggested in this article (https://leerob.io/blog/getting-started-with-dart-and-react/), I cloned the dart-react-todo repo, and I'm using Webstorm. It appears to be riddled with errors (see above, I accidentally pasted the screenshot first) I have run pub get/pub upgrade and seem to have the latest version of everything. Is this expected behavior? It seems the example project is referring to types such as TodoListItemProps that have not been defined.
    Aaron Lademann
    @aaronlademann-wf

    @dave-doty hi! I've actually never seen that blog post, or repo - so thanks for pointing it out!

    Give me a few moments to pull down the project and see whats what... hopefully I can get you headed in the right direction!

    Aaron Lademann
    @aaronlademann-wf
    Looks like that repo is still using an alpha version of over_react - which has since become stable - albeit with some breaking changes. I'm going to do a little housekeeping in there and put up a PR as soon as possible so you can get it working and try it out!
    Aaron Lademann
    @aaronlademann-wf

    @dave-doty if you check out this branch leerob/dart-react-todo#5 - everything should be working again.

    After you check out the branch, from the root of the project, run:

    pub global activate webdev
    pub get
    webdev serve

    Cheers.

    David Doty
    @dave-doty

    @aaronlademann-wf Thanks! I tried cloning from leerob's repo but I can't, I think because he's not yet merged your changes yet (I don't use git much so I'm not sure). I tried cloning directly from your repo here: https://github.com/aaronlademann-wf/dart-react-todo/tree/over_react_2_stable and got the same errors as before (e.g., "error: The name 'TodoListItemProps' isn't a type so it can't be used as a type argument. (non_type_as_type_argument at [todo_dart_react] lib\src\todo_dart_react\views\todo_list_item.dart:4)") .

    Note, this is not an error in building; running webdev serve builds just fine and the app runs (and it built and ran fine with the repo of leerob before your changes). My question is about the error messages reported by WebStorm.

    Are you sure it's the case that those reported errors are not expected behavior? The error I highlighted looks like a real error to me, since TodoListItemProps is not a type defined anywhere explicitly in the project as far as I can tell.

    My guess is that over_react does something with the "builder" to automatically create a class named TodoListItemProps based on naming conventions in the file view/todo_list_item.dart, and this is why webdev serve runs without errors. But perhaps the linter being run by WebStorm is not running this builder first, and therefore it has no idea that at runtime there will be a type named TodoListItemProps, and believes it is an error to refer to such a type.

    I'm asking whether this is expected behavior of over_react: to refer to types that are not explicitly defined in the project, which will appear as errors to static analysis tools, which are unaware that these types will be created before runtime.

    If so, are you aware of a workaround to disable such error reporting only for those types? I was really intrigued by over_react due to the ability for strong typing to help correct errors while writing source code (rather than waiting for runtime errors), but if it's going to report lots of false positive "errors", it's hard to tell real errors apart from those that the over_react builder will correct.

    Aaron Lademann
    @aaronlademann-wf
    @dave-doty after you run a build (either via pub run build_runner build or webdev serve - you have to restart the analysis server in webstorm. I added a note to the readme about that in my PR.
    David Doty
    @dave-doty
    @aaronlademann-wf Ah thanks! Works now. :)
    David Doty
    @dave-doty

    I want a component to contain a list of child components, and I wondered what type I should declare the child components to be.

    Looking through dart-react-todo (https://github.com/aaronlademann-wf/dart-react-todo/tree/over_react_2_stable) for an example, I found this: https://github.com/aaronlademann-wf/dart-react-todo/blob/over_react_2_stable/lib/src/todo_dart_react/views/todo_list.dart#L20

    @Component()
    class TodoListComponent extends UiComponent<TodoListProps> {
      /// Create a new [TodoListItem] for each todo.
      List _renderListItems() {
        List items = [];  // XXX: how to replace this with List<SomeType>?
    
        for (Todo todo in props.todos) {
          items.add(
            (TodoListItem()
              ..key = todo.content
              ..todo = todo
              ..deleteTodo = props.deleteTodo)(),
          );
        }
    
        return items;
      }
    
      @override
      render() {
        return Dom.div()(
          (TodoInput()
            ..addTestId('todoInputComponent')
            ..addTodo = props.addTodo)(),
          (ListGroup()..addTestId('todoListGroup'))(
            _renderListItems(),
          ),
        );
      }
    }

    In particular, line 20 of that file shows the List for the child components being untyped (List items = [];).

    I thought perhaps those components should have a type such as TodoListItem, but the way over_react is organized, TodoListItem is not a type, but instead a function that is called. Is this intended, or is there a way to use generics to declare what type of object is stored in the List?

    Sorry if this is documented somewhere, but I couldn't find much documentation/examples beyond the README ( https://pub.dev/packages/over_react#-readme-tab- ), so I've been crawling through that example repo to see a complete example of the intended usage of over_react.

    Aaron Lademann
    @aaronlademann-wf

    @dave-doty the children are rendered react vdom instances - which is typed as a ReactElement.

    Not all children are ReactElements though - children can be Strings, too. But in your case - your passing in an invoked builder - which returns a ReactElement.

    David Doty
    @dave-doty

    My high-level question about w_flux (as used by over_react FluxComponents) is this: how should hierarchical Stores be written when the top level is replaced?

    1) Should all Stores be created once for the lifetime of the application?
    (if so how should a parent Store update a child Store synchonously, so that the new child Store data is immediately available to the parent Store to continue its updates?), or

    2) Should we sometimes create brand new Stores to replace old Stores?
    (if so what about views that still listen to old Stores that have been replaced with newer Stores?)

    Here's a boiled-down description of my use case. I store my entire model in one object called Design. Among many fields in Design is one called items, which is of type List<item>. I'm trying to figure out how to re-implement this using Stores in w_flux that can be rendered using FluxComponents in over_react.

    The obvious way is simply to change Design, items, and all the other fields in Design, to be Stores, as well as their fields further down the object containment hierarchy. In particular, there is are FluxComponents (e.g., ItemsView) that subscribe to the items Store and render some view of it.

    The problem comes when I load a new Design from a file. The way I implemented this before was to just replace the old Design with a brand new Design (rather than mutating the existing Design in place). However, the ItemsView FluxComponent is still listening to the old Store in the old Design, so replacing the Store wholesale doesn't work.

    So I thought instead I will mutate the existing Design in place, replacing all of it piece by piece (i.e., Store by Store) with the new Design read in from the file. But the proper way to update a Store (such as items) is not to write to its fields directly, but to send an Action updating the Store.

    When initializing the new Design, immediately after initializing one field such as items, I need to access those items to properly populate other fields. However, Action updates are asynchronous, so the new items are not available yet.

    The w_flux documentation allows Actions to be awaited, but suggests this should not be done in normal production code, so this doesn't seem like the solution.

    Sorry this is a bit abstract; the real design is more complex, but I tried to boil it down to the essentials.

    Aaron Lademann
    @aaronlademann-wf
    design_view_component_demo.gif

    @dave-doty ok - so I think I understand your question - and I've built a quick proof-of-concept that should point you in the right direction.

    What I'd recommend is keeping your data model(s) separate from the Flux store - and then have your store simply have a field with one or more model instances - and use an action to update it.

    The source code for the demo shown in the .gif above can be found here - https://gist.github.com/aaronlademann-wf/515436c16989efaa7f89cc01e9a90a40
    David Doty
    @dave-doty

    @aaronlademann-wf So do you recommend against hierarchical Stores (Stores that have as fields other, smaller Stores)? I assumed that pattern not discouraged, based on the w_flux README's ComplexStore: https://github.com/Workiva/w_flux

    The reason I want hierarchical Stores, rather than one huge Store, is to avoid re-rendering the entire DOM on each Action. Perhaps I'm not understanding how it's supposed to work, but is it not the case that with only a single Store that processes all the Actions, the React view components would only have one Store they could subscribe to as listeners, so they would all be notified on every Action and re-render too frequently?

    For example, in the demo you showed, suppose there is an Action to change Design.id. There's only one Store, DesignViewStore, and the Action has to be processed there, even though it's only altering one small part of the Design. Supposing Design.items has thousands of elements (and therefore also is the number of Dom.li elements created on this line: https://gist.github.com/aaronlademann-wf/515436c16989efaa7f89cc01e9a90a40#file-design_view-dart-L24), how would you specify that the UpdateDesignIDAction, which changes only Design.id, should not trigger a re-render of the list of items?