Rudy (Next Major Release)

[quicksnap]

I was hoping we could have a tracking issue for Rudy! It would be helpful for me to watch.

I would be happy if simply this issue remained here and was closed when Rudy is ready. We don't have to make a todo list or anything... just something that pings any subscribers when it's closed and Rudy is good to go. =)

Thanks for this library. It's been really great and feels so much simpler than alternatives in my Redux app.

[faceyspacey]

sounds good. when the commits on the rudy-next branch (https://github.com/faceyspacey/redux-first-router/commits/rudy-next) start to be about documentation, we'll know we're in the clear. This is gonna be a big one, really trying to get everything right, and ultimately be a complete framework for "controller"-based React/Redux development. There's other aspects after the big Rudy launch--when it all comes together, it will be called:

"The Respond Framework"
"Don't just React, Respond."
:)

...that should give you an idea on why this has taken so long--a lot of far-reaching plans have had to be considered, plus, this ultimately is the nucleus of said framework.

---

The final things I'm working on are in this order:

• refactoring our new custom history implementation yet again. we have a middleware API all our own now, and currently history changes are transformed into Rudy actions in the middleware. I've decided it will lead to far "easier" code if I bite the bullet and refactor it so changes emanated from history are already Rudy/Redux actions, similar to the ones developers dispatch.

• the concept of route.children is something that we ultimately need if we want to be the basis for Large/Advanced apps. I wanna get that right now to prevent more work in sum that results in adding it later.

• updating flow types

• sagas + observable middlewares (they are very similar)

• apollo/graphql middleware (shares some similarities with the above 2)

• code splitting middleware tests (the actual middleware is already done).

In short, it's the first 2 that are the final big hurdles. The rest will flow, as it's primary middleware, and the whole new version is all about making it extremely easy to add powerful middleware. I already have done a lot of thinking about the aforementioned middleware as well, so I'm hoping they are relatively quick to make.

Otherwise, there's a TON of features not described here, which will just have to come out for the first time once documented.

[ghost]

Looking forward to the next version! Thanks for all your hard work!!

Everything I've wanted to do with my simple non-SSR SPA has worked great and I love this framework, it's better than anything else I've tried (and I've tried a lot of different frameworks).

[NicholasGWK]

Do you need any help? Would be down to do some PRS if that would be helpful!

[faceyspacey]

@NicholasGWK definitely could use it. Here's the list of things that don't require understanding internals:

• documentation website! -- this doesn't need any documentation to be ready to start)
• redux-observable + redux-most middlewares (after my Sagas implementation is complete and can be used as directions how to do it
• apollo/graphql middleware -- been talk to @samlevin a lot about this one, and work could be done to produce the basis for this before the Sagas middleware example is done, which is also similar (route level apollo/graphql is gonna be big!)
• typescript types (once flow types are updated)
• boilerplate + demo update (we could also benefit from SPA versions in addition)
• ToDos demo as per Real World collection of ToDo demo apps (https://github.com/gothinkster/realworld)
• Blog Demo (thunk-based one + apollo/graphql-based one)
• port of React Router components to use our location reducer state instead
• start RemiXX (https://www.npmjs.com/package/remixx) which is gonna be our replacement for Redux/MobX. It will do what both do in one. It will have first class "redux modules" (i.e. "remixx modules"). It will allow for both traditional reducers + state => ({ any, key, onState, obj }) pattern. But most importantly, it will facilitate apps where most of our components look like this:

const MyComponent = (props, state, actions) => ...

In combination with a babel plugin and a fork of https://github.com/mweststrate/immer we're going to make it so you no longer have to connect. The challenge is doing so performantly. This is part of the whole strategy of making our component code so much simpler, and moving all the complex stuff to controllers/routes. It's back to the good old days, where our component code is just rendering templates. Evented rendering templates. We're gonna drop the terminology "actions" and it will be this instead:

const MyComponent = (props, state, events) => ...

But events is just an object containing all your action creators.

As far as state goes, if you aren't using our imperative-looking MobX-inspired API (which I hope most don't), state is based on the concept that our UI database is much like an SQL database--i.e. where normalized state is taken seriously. So backing it, you'll have this:

const rootReducer = combineReducers(allReducers)
const selectors = combineSelectors(allSelectors) // similar to MySQL views and linking models together in code
const store = createStore(rootReducer, selectors)

then in:

const MyComponent = (props, state, events) => ...

state of course will lazily have access to both selectors and the reducers. It will be lazy similar to how MobX won't trigger code unless it's actually used. So selectors not used in the current rendering of the component tree won't wastefully be run.

As for Apollo/graphql, the strategy is on route changes to copy over the graphql results directly from queries into a reducer, and then continue to watch the queries attached to route.graphql for the remainder of the route/scene (yes, we have a concept of scene which represents multiple routes, children, and so on). If the cache has the data, of course, no async work will be done as well--the copy will just be made into our apolloReducer. That means we can use state.apollo.posts to access apollo data. Time travel will work, which it doesnt with Apollo. I've tried the 2.0 with apollo-redux-cache and time travel doesn't work there. That's not the main thing though--the main thing is one unified connect interface (well, our simpler one that doesn't even require that) rather than composing multiple hocs/components etc. Composing React Router's <Route />, connect and <Query /> or graphql hoc, is absurd. I have a strategy I've done some tests on to performantly do this so that your component tree doesn't re-render on route changes. In our reducer, we'll copy data out of the Apollo in-memory-cache and, use the old references for data that hasn't changed. We'll also recommend you create your rootReducer like this:

const rootReducer = (state, action) => ({
   ...combineReducers(otherReducers),
   ...apolloReducer(state, action)
})

so you don't gotta key into state.apollo.posts, but rather just state.posts. That's of course up to the user though.

Lastly, regarding Apollo, you'll of course now be able to easily select apollo UI state in combination with your UI state in your selectors! And of course reducers will get access to these actions/payloads as well. These payloads will contain the simpler denormalized data Apollo components currently receive, rather than unhelpful ones containing info about what operation was done, etc. It's gonna feel like you got the data from thunks, except you don't have to do the work of normalizing it in reducers and denormalizing it in selectors. And, again, the key to performant react rendering is re-using object references in our apollo reducer, even though after each query Apollo gives us totally new references.

Anyway, it's a misnomer that Apollo is synonymous with components. The power of Apollo is there cache. In fact, using Apollo with a proper route level abstraction like this really makes it clear how Apollo can be used without components.

As for RemiXX, obviously it's the next stage of The Respond Framework and will require lots of experimentation to get right. I bring it up because it can be harder to dive into existing code than to write new code from scratch. If that's more up your alley, we got some exciting things to lead.

The bottom line is this: our goal is to make a React framework where global state is built-in from the start as a first class concern. Controllers controlling it all (responding to requests), and components having the simplest possible API to access global time-travellable state (where the state unifies UI state, routing state + domain state [i.e. apollo/graphql]). That's the goal of this whole thing. Enough is enough already, we need our Rails moment!

ps. component composition is cool, and it's not going anywhere, but with Suspense + the Context API, it's complete. It's like "electricity"--it's behind the scenes and we aren't aware of it anymore. More importantly though, component composition of these things that were traditionally done at the route level is simply a lot more complex and results in a lot more code. It's very hard to follow the structure of these heavily composed apps. It's far easier to know you have a set of controllers/scenes/routes, possibly nested 1-3 levels deep with children, and know what all their data responsibilities are. And then have the component tree render from the resulting state, while continuing to send out events, whose resulting behavior it has no idea about. It's always been a better match to what is actually happening: a request comes in, and a response is formulated. The challenge has been that the old way wasn't conducive to reactive sub-portions of the view client side. The approach herein laid out unifies both problems with one solution.

Now, the achilles heal is simple one thing: the modularity of your actions/reducers/components. I.e. if you want to export a component from a Redux app to another app, you gotta make sure the reducers are copied over and don't collide with any keys, and the same with action creators. So whereas components can be copied over as a single unit, now we're talking 3 things. Actually 4: because the same goes for routes now. Basically, the idea is we absolutely have to nail "RemiXX modules" which namespaces both our reducer names + action types, merges shared routes, AND can be dynamically added as a single module via code splitting!

We know what we gotta do. It's just time to do it, instead of waiting around for the perfect combination of a million modular packages to be pieced together to do it. The new found modularity of javascript has been a great boon to the ecosystem. Now it's time to reel things in, take the lessons we've learned, and build a unified approach that is CRA with React Rails-level capabilities.

What's about to come out is the core. So this may sound like a lot, but we'll already be 51% of the way there once this is out. The rest is primarily just sugar, but it's sugar we need so learners aren't ushered into the pit of despair that inevitably becomes of trying to component all things.

[faceyspacey]

ps. overall, what would help the most is the documentation site. it requires the least amount of communication while i finish this up, and something we shoulda had long ago. It's red with the Rudy logo from the boilerplate. It's based on a guide feel first and foremost. The homepage should be a red BG taking up the whole screen, then when you scroll past the fold it's the easiest demo of how to use it possible with a call to action to essentially continue to the step-by-step guide. You click it and now you're in a numbered guide tutorial site.

I wanna keep it as simple as possible to begin with just to get it out as soon as possible. But it needs one special thing: half way through the guide there's a "choose your own next step" page with 6 large graphical buttons that let you choose 1 of 6 different things you can learn. And after each, it takes you back to that page, with the route you completed styled so it looks completed. There's so many things you can do with Rudy, and different people will have different things that are initially important to them. The goal is steer away from feeling like an exhaustive guide to being a quick start, plus "choose your own path" if you like it. ..We'll also of course have to have an API reference, but stylistically and layout-wise will be less special. In short, we need the "guide" to feel like an experience. It needs to stand out and be enticing, not just typical static site generator crap.

Lastly, it will be built with Rudy. The documentation itself will live in this repo in the docs folder. As I said I dont wanna use any static site generator, we're gonna eat our own dog food. So to sync the docs, we're gonna just make get requests from our node server (not the browser) to get em out of github, and cache the resulting webpages served from our node server for free with cloudflare and purge the cloudflare cache whenever there is updates. In short, because of the caching it won't matter that we get the docs via remote requests on our node server, which is likely different than what these static site generators are doing, where they live along side your docs repo. We'll be making those requests server-side via thunks attached to routes just like we already do. We're gonna use Rudy how it's supposed to be used. ..So the last bit here is we of course gotta be able to take markdown and render it in a stylistically pleasing way, obviously using one of the various React markdown rendering components. In the future, we'll have a playground to play with route options and see the state update in a devtools built into the page. But we won't do that in step1. In short, there's a lot of fun Rudy work that can be done by working on the documentation site that will give you or anyone direct opportunity to learn the ins and outs of Rudy from me, while being in charge of a relatively simple but complete product you can take credit for. Reads: you don't gotta be an expert on the internals of Rudy to make a major much needed contribution, while also in fact mastering Rudy and all the new features the new API offers. Someone with strong CSS skills and eye for design obviously is a better suited candidate.

[klis87]

@faceyspacey Thats seems really impressive what you are doing, I cannot wait for the next version. But I am concerned about one thing, will Rudy version be similar to this one, but just more modular, which we will be able to connect to Redux, Apollo or your Respond framework? Or you will focus to get rid of redux eventually and support just Respond integration? I am asking because really I am only interested in routing part, to be able to keep routing state inside redux, without changing how my apps are structured - I am really concerned about word "framework" :)

Btw, what exactly Rudy is? :) I must admit, I have never been so confused regarding any library in my life :D

[ghost]

...I am only interested in routing part, to be able to keep routing state inside redux, without changing how my apps are structured...

I have the same concern because I have built a huge app that relies on this. However, I am fully capable of maintaining it myself and in preparation for that I forked all the repos, just in case.

[faceyspacey]

Everything will live in Redux when the next version of RFR comes out (renamed to Rudy).

Eventually we will make a Redux-compatible store called Remix.

Then the framework will use both of our primary libs.

This repo has very few bugs, it’s always available to you.

[nate-vukovich]

Is there a realease date planned? Or could it be speculated?

[mattoni]

I'm super excited, I used to tear my hair out dealing with the seemingly opposite frames of mind when it came to routing (even tried building my own super simple router, and it worked for the vast majority of things) but RFR has been the first system that felt natural. Happy to see its progression and will be using it in some massive projects (https://cycle.io)

I might be able to help with Typescript definitions as I'm pretty familiar with the space. Ping me when the Flow types are done and I'll see if I can help.

[faceyspacey]

Thats awesome. Always great to here. Cycle.io looks suite!!

I'll definitely hit you up regarding the TS.

[simonjoom]

Hello community i just created a Apollo boilerplate using the last branch rudy and some feature with webpack4 want to share i'm looking for developer ready to work with me .

https://github.com/simonjoom/Apollo-RFX-PRISMA-ssr-boilerplate
install easy and running too. npm install && npm run start

inside:
react universal component for layout page with splitting dependencies
style management (scss) (font-awesome and basscss for css)
rudy (redux first router) of course
different webpack plugins cache for fast developpement
using apollo-redux-cache to allow apollo working with rudy .. indeed i still didn't test the time travel..
some code taken from create-react-app and different major boilerplate;
webpack4 features bug resolved after looking through internet

at the end you have a very nice workflow .
your application working with the apollo playground for api graphql .

don't hesitate to ask me

[ScriptedAlchemy]

@simonjoom do you NEED webpack for or saying you fixed it?

faceyspacey/extract-css-chunks-webpack-plugin#60

[simonjoom]

it's fixed for me. look in Apollo-RFX-PRISMA-ssr-boilerplate you can take https://github.com/simonjoom/Apollo-RFX-PRISMA-ssr-boilerplate/tree/master/extract-css-chunks-webpack-plugin

i used and merge inside a code hotModuleReplacement2.js from mini-css-extract-plugin to allow the hot-reload work better with webpack4

to use it maybe you should had ./extract-css-chunks-webpack-plugin/hotModuleReplacement2 in the entry of your app, i don't know why else webpack4 do not bundle it.

[ScriptedAlchemy]

Looool love it! I’ve done something similar too!

[simonjoom]

please have a test in this boilerplate. i need some support too ;)

[ScriptedAlchemy]

Webpack 4 CSS chunking and HMR if anyone needs it:

https://www.npmjs.com/package/extract-css-chunks-webpack-plugin/v/3.0.0

[simonjoom]

I see a version mini-css-extract-plugin :) the hacky mine is still working but version webpack-text-plugin.
There is lot of work you did. could you explain briefly the difference between?

[ScriptedAlchemy]

@simonjoom haha yeah. Forked it - much like what was done with extract-text-plugin.

I pretty much took it as is, then added HMR onto the plugin. Id like to look into upgrading it to use Tabbables tapAsync hooks. I think overall, its was a good move to look at mini-css as a starting point. It will give us insight to what webpack has planned at some point in the future.

[paul-sachs]

Any word on Rudy? Feel like i haven't heard anything in a while.

[hedgepigdaniel]

Hey, thought I'd check in here because I'm really excited about where this project is going and I want to contribute in some way to its development and getting it out to a wider audience.

Is the docs website still in a TODO state? If so I'm keen to make a start on that. I've done a few projects with RFR and very much keen to try out Rudy, and a friend of mine is a UX designer and is also keen to help with that side. @faceyspacey if you're happy to provide some guidance/feedback along the way we can get started :)

[soundyogi]

Just wanted to chime in. How is the progress?
A Crude Usage example in the current branch would be nice.

I had to buil my own rfr version since the newest one does not return values from dispatch()
the new rudy version can. but I dont know how to integrate.

Maybe We can help.

Please I dont want any other routing lib anymore lol.

[faceyspacey]

Hey guys, the documentation website is something we definitely need help with. It will be built with Rudy, so it will be a fun collaboration. And it will need to look and feel great.

That said, it’s really kinda hard without me at least writing out initial docs that cover the full breadth of what is available. There’s A LOT of new stuff, including our own async middleware api based on the koa pipeline.

We also need to make a sagas and Apollo middleware. That may be something u guys wanna work on, as it doesn’t require knowledge of the whole codebase. It is plugin api after all—you only need to know its interface.

——
Ive been taking a step back and researching as much as I can in adjacent technologies/languages. Before releasing this I really wanted to make sure we have covered all our bases. So I’m a few days away from coding this again full time. And we are very close to release. Ultimately I need to get a draft of the docs out before communication can be efficient, or the same things will get explained multiple times. Hold tight guys, I really appreciate the interest. I think ur really gonna like what u see once it’s out. Give me just a little bit longer and that time will come.

Lastly, @ScriptedAlchemy has really been a godsend in helping me with these libs. The challenge I’ve had is that we need more developers contributing in various ways. I ended up coding this entire past year once I saw the big vision, instead of promoting the libs like I did when first released, which is why the libs aren’t as popular as I think they could be. We have a really nice stack that ultimately is under appreciated by the industry. We are basically the React guys sticking to the dream of App = f(state), whereas most developers have given up on their apps being realistically driveable from a single state atom. They may use redux, but not to its full potential. We solve the challenges here by coupling key capabilities to the global state store: routing state, ui state, domain state (graphql).

Redux’ weak spot is modularity, which is why the greater react community and experts are sticking staunch with components. But we can have the best of both worlds and bring modularity to redux. Aka “redux modules” or “redux components.”

The “component everything” approach promoted in the mainstream provides very granular modularity at the expense of tremendous amounts of busy work piecing it together, but more importantly misses out on some extremely powerful automatic automated testing capabilities that you can achieve when you follow the single state atom concept to the bitter end. Basically modularity a step up for sections of ur app rather than for small components is what we are gonna provide. This addresses both the lack of redux modularity and the general issue that granular component level modularity is too low level. We need something a bit higher to achieve independently testable sub apps (micro frontends or whatever u wanna call it), while avoiding the busy work (and points of failure) introduced by hocs, render props, etc. This approach must also let you bind ur sub app to a parent app, like a giant component. And of course your routes, state keys, thunks/sagas etc must automatically come along for the ride. This lets small groups quickly iterate new features without worrying about breaking a potentially very large app. “Redux component modules” will do a lot to validate our otherwise “monolith” approach, which the guys at React/Facebook clearly and rightfully aren’t too keen on. In other words, we are gonna have the best of both worlds!

...So these are a few clues about the importance of this stack, where it’s going, perhaps why it hasn’t become super popular (minus the fact I’m not Facebook and cant imbue instant popularity on a package by virtue of releasing it). We have a better story than what’s been being told about React the past 3 years. We just gotta tell it.

There’s a large opportunity here for developers that wanna essentially join our informal group. If ur serious about contributing, email me at [email protected]. There’s an opportunity here to be authors of popular plugin packages by simply being the first. Sagas, observables, apollo/graphql, etc have special connections into Rudy on top of what they are already doing with redux. Rudy will be promoted heavily, so assuming it becomes popular, so will your libs. And ultimately popular libs === job/project opportunities. A real merit based structure we can climb has been produced out of the open source decentralized npm/github world we live in.

[soundyogi]

Hi,
I think its admirable what you want to do with the project and the outlook sounds extremely Interesting.

But as I see it theres a big problem.

I have no Idea how to integrate the @next version. (just replacing the package does not work)
The latest rfr version does not work as it should either.
(I had to hack my own version because dispatch did not return values, but the details are not important, the problem is that its confusing)

I DONT WANT TO BE AN ASS.
I LOVE THIS ROUTER.
And maybe this whole comment is moot since you said:
'And we are very close to release. Ultimately I need to get a draft of the docs out before communication can be efficient, or the same things will get explained multiple times.'

But,
in the current State the project has a weird taste to it.
is rudy usable? is rfr abandoned? why are changes in rudy that are not in the latest rfr branch.
Do you use rudy already in real world applications?
if I should use @next , we need at least simple docs on how to use it. its elementary as I see it.

I wrote a large-ish-dApp-frontend with my-custom rfr version and I was pretty happy with that.

Now, I find myself in the position to write interface for public transportation systems in 24 countries worldwide.
How Am I going to sell this router?
The answer is, I cant at this moment.
I cant be sure you support rfr, I have no idea how usable rudy is.

So while I want to help and contribute and love this project.
I am missing KISS.
Maybe its me being stupid. But the experience was not very pretty so far.

The problem is that the premise works way to well and is superior to any other routing lib.
I admire what you want to do. Maybe its also time to backpeddle a bit and just get the basic rudy out so ppl can actually use the lib and go from there.

You talk about redux modularity, which is awesome.
But I thought this was a routing library. And I am very confused where this is going to go.
There many many many ways to make redux more reusable.
(Standalone React Components that create a Store at mount and namespaced-generic-reducers are my favorites atm, but that does not matter, why should the router be concerned with that)

Maybe my problems are solved with a simple 'how to integrate rudy@next' doc.
(Because atm, I have no idea how)

Please dont take this the wrong way.
I have nothing but love for the project and probably could help and even get time for it from my current project employer. But as soon as the other Engineers would compare rfr/rudy to react router 4 we are out before they even got why rfr is so super awesome. I cant sell it to them.

If you ask why the project is not that popular I would say this is the reason:

@klis87 comment:
'Btw, what exactly Rudy is? :) I must admit, I have never been so confused regarding any library in my life :D'

and
@waynebloss comment:
'I have the same concern because I have built a huge app that relies on this. However, I am fully capable of maintaining it myself and in preparation for that I forked all the repos, just in case.'

Which is essentially what I have done.

But that wont work for coorporate environments.

I am just afraid that we have something groundbreakingly good here but the feature creep comes and eats it up.
Using RFR is simple. easy. There is almost nor framework at all just business logic. I really liked that.

(the fixes I made to rfr were included in rudy, but integrating rudy seems to be different than rfr the result is confusion)

Maybe rudy is not really the next version of rfr. Maybe its a new project? Something much bigger?

Thanks for reading my unstructured rambling
<3 <3

[klis87]

I think similarly to @soundyogi . I will add things from myself though.

@faceyspacey I really admire what you give to community, not only this router but also you were the first person who truly achieved correct SSR + code splitting (excluding next.js).

Your plans are very promising, but challenging and long-term - all of this requires huge amount of work and time, especially looking from what you write is that you are the only one developer for now. Please take one thing into consideration, you mentioned that your libraries are not as popular as they should. Reputation is really important and project with uncertain future won't be picked by many devs no matter how good quality is, the risk is just too big. And this topic seems to be quite popular because people are really waiting for this router to stabilize on master branch, but you could lose some of them with smaller patience.

From what I understand is that your plans are to replace redux with something else, but RFR is just redux addon, with only routing included. Most experienced developer have their favourite tools and it will be really hard to move them out of redux or graphql clients, but many of them would switch from React Router 4 to RFR because it is just a better solution if someone uses redux. And I feel that state of this library is almost done, just pushing it a little into stable master with good documentation would be great, and community could make PRs to help you develop in further, which right now is impossible due to master/next/rudy unclearity.

[soundyogi]

The Confusion Continues.

From what I did understand the goal is NOT TO REPLACE redux.
But have a canonical way that deals with its shortcomings.
WHICH IS A HUGE UNDERTAKING.
And who does this right as the first will probably write history since redux-architecture is here to stay if you ask me.
Also, I know @faceyspacey can pull it off.

We all probably cannot even begin to understand whats in your mind and it sounds like the new 'router' would also depend on many of the things you want to implement.

Maybe all we need to do is fix the last redux-first-router version, call it final. And then we/you have all the time in the world to implement the new shiny rudy (lets call it framework?).

This way we would have less confusion. A working router. Could advertise rfr (which of course can mention rudy everywhere). And have a more coherent experience.

[qodesmith]

This conversation has me confused. Is Rudy going to be a routing solution for React + Redux apps? What is the talk of a framework? In the React ecosystem, we basically piece-meal together our own "framework" - aka React + Redux + whatever-other-tools-you-need. So I thought this router was another piece in that chain.

A colleague of mine put me on to RFR as an alternative to React Router and helped convince our team to use it instead of React Router. I'm unclear as to the intentions of the future of this project. Is it going to remain a routing solution or is this becoming something completely different? Is there a tweet-sized definition of Rudy? Can we expect a routing solution or is this now a different project?

[whitmanschorn]

Not to pile on, but I am also concerned about the direction rudy is taking.

Much like @soundyogi , I love this redux-first-router! However, I am thinking of forking my own version or switching to an inferior solution because rudy (and the whole future of the library) has become too much of an unknown. RFR is a revelation after you've worked with react-router, but it's also small enough to easily incorporate into an existing project. Rudy, while awesome, seems like it would be a much bigger 'sell' to other members of my team.

Basically, @faceyspacey , you're doing great work, but you don't have to fix EVERY problem in web development in ONE release! People are already getting a ton of value out of plain rfr, and I predict you will see more contributions in both projects if you clearly separate them.

[ScriptedAlchemy]

@faceyspacey addressing some concerns that the community is raising here.

What are your thoughts of us patching up the core, as we have planned, adding <Route and <Link and a couple other of the core parts that currently exist in the Rudy branch we are working on.

Much like Universal, we could, maybe... introduce out add-ons as actual middlewares?

Basically, we solidify the core, and turn more stuff into middleware integration layers which can live in a monorepo or as their own products. This could mean shipping with less, but we might stand better chances of strength in numbers if we were to treat some internal things as add-ons to the middleware.

After using Rudy, our one, the latest branch. It really is a huge upgrade to an already awesome project.
I'm in Oregon for the rest of the week, but next week - we should set up a call and see if we can fast-track the remaining parts that we need to make it complete.

Id really love to start using our later versions man. It might be worth using our own middleware API and tack on some of our features as plugins.

[pho3nixf1re]

I would be willing to work on that, It is now a critical part of our apps and as such my day job is open to helping some with this project. On Jul 25, 2018 20:27, Zack Jackson <[email protected]> wrote: @faceyspacey addressing some concerns that the community is raising here. What are your thoughts of us patching up the core, as we have planned, adding <Route and <Link and a couple other of the core parts that currently exist in the Rudy branch we are working on. Much like Universal, we could, maybe... introduce out add-ons as actual middlewares? Basically, we solidify the core, and turn more stuff into middleware integration layers which can live in a monorepo or as their own products. This could mean shipping with less, but we might stand better chances of strength in numbers if we were to treat some internal things as add-ons to the middleware. After using Rudy, our one, the latest branch. It really is a huge upgrade to an already awesome project. I'm in Oregon for the rest of the week, but next week - we should set up a call and see if we can fast-track the remaining parts that we need to make it complete. Id really love to start using our later versions man. It might be worth using out own middleware api and tack on some of our features as plugins. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Enalmada]

When I first read the idea to rename away from "redux" I was shocked at the loss of key seo search terms ...but I have changed my mind because I am starting to feel like redux may actually have peaked more than people realize. Here is some food for thought:

graphql clients are not only making traditional rest api look old, they are now aggressively providing overlapping features people traditionally used redux for (apollo / relay). The dev tools are not even close to mature yet but as they improve along with the functionality provided by graphql clients, redux is looking to me like it could become redundant.

ReasonReact, which facebook is converting its internal production code to, provides router and reducers natively. ReasonReact features, dev tools, and typesafe bindings on top of existing js libraries are still being actively developed but after playing around with it, the benefits are so compelling (goodbye flow, prop-types, immutable.js, import statements, etc) that adoption will be rapid once Facebook says "its ready". The combination of Apollo state + Reason reducers could deprecate redux. I am not confident the native reason router will be everything people need for a while...it doesn't support ssr yet and is clearly not a priority for facebook.

It might be worth considering how rudy and eventual respond framework fit into a potential post-redux "Reason/Apollo" world.

[ScriptedAlchemy]

PR open for RFR #287

[ScriptedAlchemy]

@CNDW We need some help on rudy-respond. Mostly, if you like i can invite you to my slack channel and we can discuss it a little easier over there.

Right now im pushing to get some updates out the door on RFR and Universal. Then we need to expose the internal API to a level where developers can write plugins like apollo integrations and so on. Essentially something robust enough that we can ship the core and allow devs to extend it.

We need more examples of what rudy-respond can do to be showcased in the boilerplate

We also desperately need tests to be fixed and updated

I would have liked to dedicate more immediate time to rudy-respond than I have - however Universal has grown substantially in active users -- forcing me to prepare a v4 release.

[gmattar]

Hi @ScriptedAlchemy, thanks for the awesome work!
Is https://github.com/faceyspacey/redux-first-router-demo still the latest example of Rudy+SSR+ code splitting or are you shipping anything new together with Rudy@next?

Thanks again!

[ScriptedAlchemy]

It’s extremely outdated. I don’t have write access to that one. However, in the newest PR I opened it should have a demo inside it?

Rudy Respond definitely has a demo in its branch.

I’m on my phone at the moment so I cannot confirm this. Most of the release I’m shipping was before my time. I’m just coming in at the last mile to push it out the door.

Check out my pull request. It’s well documented thanks to James and Daniel

[gmattar]

Rudy doesn't have an example, only documentation.

[ScriptedAlchemy]

@gmattar ill fork the demo under my account and update it - it needs it anyways :)

[gmattar]

nice, thank you!

[CNDW]

@ScriptedAlchemy the slack invite link you posted earlier is expired, is there another one I can use?

[ScriptedAlchemy]

@CNDW https://join.slack.com/t/scriptedalchemy/shared_invite/enQtNDM2ODQ2ODg4ODk3LWJjNjI3ZWZhMGFkZTY1Y2E3MTZlMjVmNzAyMzQxY2EzNTk3NDBhMGY2NTg5YThjNDI5NDVkZjNiYWUwYWM5ZjY

[ghost]

What are your thoughts of us patching up the core, as we have planned, adding <Route and <Link and a couple other of the core parts that currently exist in the Rudy branch we are working on.

@ScriptedAlchemy are you able to elaborate on what <Route> is? Is it a way to specify which component to render for a route, more like react-router does? I've tried searching through various branches but I can't figure out what exactly you were referring to.

Thanks!

[ScriptedAlchemy]

Hey everyone.

Heres an update!!
Rudy: Im ready to release it. Spoke to James today (faceyspacey) -- getting NPM access sorted out. Once thats done ill be releasing this incremental update

Rudy-Respond: This is the mega update => Complete rewrite. There is one feature outstanding - after that. James has given the green light on releasing it.

Whats left for Rudy-Respond?

• Tests need updating (not a blocker)
• Documentation needs updating (I might fly down and meet up with James - ill hammer out all the notes i need, then write the docs up)
• We need nested routes! /
  -- this one is a blocker. I can put out a beta but nothing more will be released till this feature is completed.

I am locked up for a few final weeks. Then after that I plan on working on it.
@micmcg - I know you had mentioned adding this feature and (potentially) contributing to it.

If anyone would like to join in on a collective effort at some time in late October - we can finally make this thing a reality!! Ill have the docs ready beforehand. Or at least the notes i take from my time with James. Pretty much i can unblock us ahead of time so that in like a months time - we could (hopefully) put out heads together, and have the last requirement nailed quickly.

I know many of you have been waiting for this big release. Its a huge effort for those involved, Im extremely thankful to some key people in the community who have played an integral role in getting the project this far.

If theres anyone who can contribute to the final feature, please join my slack channel and send me a message. I should be available to work on this personally in about a months time. So if anyone wants to join together in a month- hit me up.

Whats the plan for <Route

Well, going off the original email from James
We wanted to cannibalize some of RR's implementation, avoid the performance issues of RR.

We also need a Route component like react router, but where it also has built in code splitting and can show a spinner until a component is available in state: <Route loading={Spinner} component=‘Foo’ type/path=

Since u did code splitting already, the route component ur gonna love making. Look into my urlToAction and actionToUrl utils as well as the path matching functions they call. The matching functions were born out of React Router code. U will use them to make the path matching portion of our Route component. Look into React Router’s codebase and see how they do it. Look at their Route component.

Our Route component can match on types as well as paths like in React Router. Perhaps even match on params, etc, in a second iteration. But otherwise it’s very much intended to feel like React Router’s route component. Ie we are leveraging familiarity. So we are RR’s component but with type matching and code splitting. See how the component is passed as a string. That’s because it gets the component from state rather than has passed in like in RR.

Wheres my time going? (why havent i built it yet)

I left my job and relocated to the west coast. Since I've been here, I have been contracting and implementing RFR or Universal systems for companies. Some tight deadlines kept me busy

Theres a set up updates I have been focusing on for Universal. This was unplanned, but as the popularity grew substantially, i had to do a decent amount of work across the whole system.
Universal has been finalized for releases, including a React 16 API. Theres a few things left i must do, then releasing it.

Once released, whats the plan

Ill keep supporting it regularly, first goal is to prepare a branch for React 17 (Suspense) - which should land late this year or early next year.

Ill be building Apollo and GraphQL middleware into Rudy-Respond, enhancing our new internal API to give developers the ability to write low level middleware we can merge back into out new monorepo / just let devs build cool middleware for themselves.

Finally, Im going to start on the Respond Framework. This has been mentioned lightly.

Rudy-Respond, while standalone. Is part of a larger effort @faceyspacey has been working toward for a very long time. This is a effort that I fully believe in and fully intend on seeing through.

Respond Framework is our interpretation of a "Rails" like system - a react MVC.
Remixx is us rewriting react-redux to allow things like async redux modules, ways to teleport, freeze, and track redux events, modules, runtime, and stores.

Overall, Respond is our attempt at speeding up some of the mundane tasks we find ourselves in with React. Things like wrapping connect statements and withRouter. We want to leverage What we did on Universal, but build it in (or use Suspense). Building a Respond App should be significantly faster, yet just as flexible as a react app.

Respond has a devtools api. We plan to make a plugin that automates tests. Because we track all events from redux, and because respond uses events to drive the whole architecture. We are able to replay a set of actions collected during the development of the app (like a storybook recording the actions or something). We then can snapshot the action and their result and pretty much run the actions and results instead of trying to spy on and catch things.

Im actually looking at getting a computer science degree, so I'm considering enrolling in a University that has an online offering. During the development of faceyspacey products, Ive realized that once Rudy Respond is out, I dont actually have the low level skillsets I want to develop Remixx.

For now though, <Route is the goal :)

Hopefully this brings a little transparency to whats going on

TLDR;

• Im looking for help on the final feature of Rudy-Respond <Route component system,
• RFR's Rudy update is ready to ship and releasing it as soon as i get NPM access.
• Once Rudy-Respond is out, ill build middleware for apollo
• Responds Remixx is the next thing ill move on to once Rudy-Respond is out
• Thanks to those in the community who have helped us this far <3

[fetchTe]

I'll take a look at implementing the <Route component system this weekend but it sounds pretty straight forward. Nonetheless, big thanks to everyone especially @ScriptedAlchemy for spearheading this release and @faceyspacey general awesomeness.

[ScriptedAlchemy]

@artisin that would be really fantastic - make sure you are on the rudy-respond branch, any progress is a huge help - at the very least we have broken ground - ill be jumping in on this effort in the third week of October

I have a slack channel if you'd like to join - be easier to communicate.

Again, thanks to everyone whose helped get this far. Ill be far more hands-on later this months once all my other releases are done.

FaceySpacey might be quiet around the repos - but I am in regular communication with him. Each step I've actioned is through collective planing and progress updates.

[ScriptedAlchemy]

Hi all, I have started working on a very very basic and hacky solution. Just so theres some progress.

Ive never really dont Routing before - at least not the JSX side of things so im pretty sure theres a better way to doing things.

If anyone wants to Review it or commit a few lines of code <3

Every step is a step closer. Ill dedicating all my resources into developing and releasing Rudy Respond

#296

[ScriptedAlchemy]

Okay i have NPM access. Preparing to merge. Keep a look out for v2.0.0

Removing all these confusing tags too.

Rudy Respond will be on an alpha tag a little later this week - it might be its own repo under the respond organization. But till then ill provide a alpha tag in the readme

[ScriptedAlchemy]

Working on releasing #287

Tests passing, working on some final updates.

All tags are gone on npm, please use v2.0.0 after merging <3

Ill be opening a new repo under the respond-framework, itll have Rudy and ill be opening a npm alpha for it to be tested out.

I really appreciate your patience - it brings me great joy to get this in your hands

[ScriptedAlchemy]

2.0 released RFR will become LTS while Rudy receives active feature updates.

More news to come soon

[ScriptedAlchemy]

Hey all

An update:

RFR 2.0 !== Rudy

I have released RFR 2. which is know to some as @rudy on npm. In reality, it is a breaking change update which will be supported long term. The documentation is still a little shotty, so i encourage those in the community to PR and take creative license when it comes to documenting.

There are a few from the community who are upgrading and agreed to assist with docs, if you want to join in, get me on slack and check the documentation channel.

As for RUDY (Rudy Respond) - I moved it to a new repo, im working out some naming conventions with @hedgepigdaniel - after that, ill release an alpha tag on NPM for those interested in beta testing Rudy.

[iiroj]

@ScriptedAlchemy Sorry if this is not the place to ask, but since you updated RFR to 2.0.0, the Typescript definitions should probably be updated as well. It's a pretty breaking change since connectRoutes takes different arguments.

I'm using @types/[email protected].

[ScriptedAlchemy]

@iiroj is there any chance youd be willing to help ammend it?

Ive never used TS - but i can remove it for the time being if it causes a problem? Then add it back once i get round to it?

[threehams]

@types/redux-first-router is community maintained, not controlled by anyone here. Source is at https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/redux-first-router.

[ScriptedAlchemy]

Thanks for the input! Had no idea 😂😂

Sorry guys I only work with Flow and React

Willing to help where I can though. But TS is something I’ve never needed to write.

[iiroj]

I'll see if I have time and create a PR there. For now I'm not using TypeScript + RFR in production anywhere, so it's not too time-sensitive.

[ghost]

Hey, I've upgraded to the new version (2.0/rudy) but I've hit a snag with removing the memory portion from configuring the store, server side no longer knows which page is being requested so it always sends the homepage. Did I miss something or was this overlooked? Sorry if this isn't the right place to post this. Thanks!

[Bobgy]

@DragonFire353 the new initialEntries option is just like the one you used in createHistory, https://github.com/faceyspacey/redux-first-router/blob/master/docs/migration.md

[ngbrown]

@ScriptedAlchemy is a version 2 of redux-first-router-link also going to be released? Right now I'm still needing to use 0.0.3-rudy for the basename support.

[ScriptedAlchemy]

Lol yeah I need to. I just forgot and honestly there’s not been much hell raised by the community to remind me.

Heads up, I’m on a lot of OSS projects. So if there’s pressing issues - bug the hell out of me so it higher in my mail