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 /> orgraphqlhoc, 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?

https://github.com/faceyspacey/extract-css-chunks-webpack-plugin/issues/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 james@faceyspacey.com. 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 notifications@github.com 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.

[paul-sachs]

I'd also like to help. I'm using this in some projects and don't want to see it fizzle. On Wed, Jul 25, 2018 at 9:38 PM, Matthew Turney notifications@github.com wrote:

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 notifications@github.com 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.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/faceyspacey/redux-first-router/issues/218#issuecomment-407948532, or mute the thread https://github.com/notifications/unsubscribe-auth/AK61gLdXGk5hkizMMPpfEqQm-yka5kODks5uKR2lgaJpZM4Skr49 .

[ScriptedAlchemy]

Matthew, mail me

Zack@scriptedalchemy.com

Sent from my iPhone

On Jul 25, 2018, at 6:38 PM, Matthew Turney notifications@github.com wrote:

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 notifications@github.com 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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ScriptedAlchemy]

@primozs @pho3nixf1re @NicholasGWK @mattoni

Lets move this either to a mail zack@scriptedalchemy.com or here's a slack invite.

https://join.slack.com/t/scriptedalchemy/shared_invite/enQtNDA2NjgxNjI2NTE5LTJlN2M4YzEzMjA1OGQxN2Q3ODI2ODQ1OWQ2ODkyZDJiNDE1ODNiNjY1ODc3MmQ1NDg4YTVlZDA3YWRjZDkzZWM

I understand you guys might be interested in helping drive this forward. I'm willing to lead and onboard any parties willing to help package Rudy into something we can release sooner rather than later. @faceyspacey I'm aware I'm taking a little initiative here and jumping the gun. I and the community strongly believe that RFR is the best thing out there, Having personally worked on and with Rudy..... Man, its GOTTA get out there in some form.

Until @faceyspacey gives a solid okay, no merges to master, but we should be able to get something up on NPM, like an alpha which all of us can benefit from.

In my true and honest experience, the amount of times I've said "damn Rudy would solve all this for us just built in" is in the dozens.

Rudy is something that I just can't live without anymore, even if some features are stripped off it for an alpha, its still some of the most elegant work to date.

I've given up my job to move into open-source dev & architecture consulting - the main driver bring Rudy and Respond.

This is a call to all developers willing and able.

If you like what you see, and can follow along to this branch, let's make some magic. Helping James with his various and amazing projects have been one of the best choices I've ever made. It might be hard, complex, and test you at times. But its worth every damn hour.

Check this: https://github.com/faceyspacey/redux-first-router/tree/rudy-respond Then click this: https://join.slack.com/t/scriptedalchemy/shared_invite/enQtNDA2NjgxNjI2NTE5LTJlN2M4YzEzMjA1OGQxN2Q3ODI2ODQ1OWQ2ODkyZDJiNDE1ODNiNjY1ODc3MmQ1NDg4YTVlZDA3YWRjZDkzZWM

[btmorex]

Is there any chance of another official release of redux-first-router including the redux-first-router@next stuff and maybe some of the bug fix pull requests?

It still seems like rudy is pretty far off. I have one project using rfr which won't change, but I'm seriously considering other routing solutions for new projects simply because they're maintained.

[Enalmada]

I just stumbled upon react-first-router and I am amazed it is not the standard given the popularity of redux. I sense a faceyspacey as Nikola Tesla vs React-Router as Thomas Edison thing going on. Here are some suggestions to keep this project healthy:

As excited as you are about "rudy", I urge you to take just a moment out of your day and make the public facing aspects of redux-first-router feel actively maintained...this is critical for new users to feel confident adopting it. I know you guys are super busy and I don't believe it would take much time, this project just needs some quick dusting while you do your mad science behind the scenes.

Make "next" the current release along with any easy/obvious bug fix pull requests. All the demos/samples out there use redux-first-router@next as if it was the official release anyway. First thing many people do before adopting a new technology is check the last release date. Get a current one up even if what it contains is trivial.

Put all rudy talk/info at the bottom of the github page. Talk of "rudy" confuses new users that first need to be converted to RFR before attention span runs out. Old update dates at the top of homepage make the project seem abandoned....move doc info into appropriate docs section.

Finally, you need to have a "come to Jesus" moment about scope creep. Get the rudy alpha out right now and call it redux-first-router v2.0 GA. Yes GA....nothing is perfect...let the community help with fixes/enhancements from where you are at. Ask the community to start using it and begin incrementally adding and releasing features/fixes as they are code complete. "Next" should be back to getting community pre-release testing/feedback for a week or so before GA release. It isn't healthy to be sitting on a huge amount of brilliant "rudy" code that is so far from where the community is at. Many contributions come from normal people wanting to incrementally contribute a feature/fix based on what they are currently using in their production environments. Close the gap from where production is at (1.9.19 Aug 23, 2017) and where rudy is at so the community can work with you rather than wait for you.

[Grsmto]

If that can help, I've been using RFR on https://everpress.com/ , (took the decision in January when the plugin was still quite maintained). Since that the app has grown up and I'm very happy of RFR and the way it works. I had to solve a few issues but nothing has been blocking and it feels all much more natural than React-Router in the end. The current state of RFR is already usable in production and just works. I think the authoring of the repo should maybe be given to another maintainer while Faceyspacey does its stuff in the background.

[nyenye]

As of next month I'll start development of an internal product for my company, and I'll be using RFR, because I've used it on a project I worked for in the past, and I really liked it. But really it's confusing seeing that RFR is no longer maintained in the slightest, and reading people saying that it has issues still to be addressed. I'm guessing I should use the @next branch? Or maybe use @soundyogi 's fork? Thanks in advance for any insight on this topic.

And on a side note, has anyone been in contact with @faceyspacey? I'm guessing he must be out on holidays or something, because it's been a whole month since last message from him.

[hedgepigdaniel]

To add some clarity to anyone who is confused about what is going on:

• The 1.0 version which is tested and stable is available on npm as the rudy tag and reflects the rudy branch. To get it: yarn add redux-first-router@rudy. The docs in the README on the master branch reflect this version. Some of the features mentioned in the README under "Updates" are not included in the docs folder (e.g. the "extra" argument). There isn't much point using the outdated master and next branches.

• The 2.0 rudy-respond version is in development at @ScriptedAlchemy's fork, on the rudy-respond branch. I believe @ScriptedAlchemy has been in contact with @faceyspacey and hopefully he will be back soon. In the meantime, its an open source project, and anyone is welcome to contribute. Follow @ScriptedAlchemy's fork, join the slack he set up, talk to us, and help us get rudy-respond ready, do any necessary maintenance on redux-first-router 1.0, or anything else you think is important.

• I've recently started doing some basic work on the rudy-respond branch. There's alot to get your head around, and a fair bit of polishing to do in terms of developer experience, build, CI, testing, etc. Most of the basic features seem to work though, and the code is really nicely structured. There are alot of useful new features over 1.0. The demo/example in examples/boilerplate is functional and demonstrates (in a rudimentary way) some of these new features.

[ScriptedAlchemy]

Thanks for the input here @hedgepigdaniel

[ScriptedAlchemy]

Hello everyone.

Firstly, Thank you for the continued support and interest in this project.

Ive been following the communities comments closely, working on a good path forward that addresses many concerns that have been brought up.

@Enalmada @Grsmto @btmorex -- I am pleased to announce that Ill be updating documentation and releasing the branch known as rudy currently installable and a next tag on NPM.

THIS IS NOT RUDY (sorry for the confusion), but a healthy update which shouldn't introduce breaking changes to the api. For clairty on the naming confusion, check Daniels comment https://github.com/faceyspacey/redux-first-router/issues/218#issuecomment-415930092

If there are any issues with RFR, ill be reviewing PRs, Releasing Updates, and issuing fixes.

Please allow me a few days to prepare the release :)

What about rudy-respond? (the complete rewrite) I know theres been some hype around it!

Heres where we are at:

Thanks to @hedgepigdaniel - who has been incredibly helpful & generous with his time. We have rudy-respond stable, a working demo, and some refactoring. It will be released on npm under a tag for the public to test out (there is no documentation at this time, and i do apologize for that - we are working on it but significantly under-manned to do everything)

@whitmanschorn -- Ive probably taken your comments most seriously, it was one of the main motivators to try and orchestrate a release strategy for the community. Based on your feedback and some help from generous developers, ive commissioned something stable - lacking some features, but does everything and more that RFR can do. @hedgepigdaniel moved things to a lerna repo, and my goal is to try and use the publicly accessible api to build out some of the features (apollo, and so on) - this would mean the core is thinner, and devs could write / install additional middleware from our scoped repo on NPM.

I will also work on some kind of document which can be updated, giving some transparency to the community as well as more general information on our progress.

TLDR; Ill be actively maintaining RFR, releasing an incremental update known as rudy and putting the major rewrite which is now stable on npm under an alpha tag. This project will be maintained, on a regular basis from this point forward

Thank you for your patience, I want to ensure everyone that this project will be actively maintained. Feel free to PR the project and reach out to me if theres anything you need.

[ScriptedAlchemy]

Working on documentation updates to officially release the @next tag. Once released - we will work on getting an installable version of rudy-respond up somewhere. We are trying to add on some nice-to-haves for the its first alpha - while documentation might be outdated, incomplete or a WIP. The demo is serving as the testing grounds for new features and we will try to display as many as we can. Ill keep you up to date on documentation stuff.

I also will be using twitter to send out updates regarding Rudy-Respond. So if anyone wants to follow me @ScriptedAlchemy is the handle.

I am also considering a wiki for easier content organization and management

[CNDW]

I've got some skin in the game on this project and would love to pitch in whenever I get time. Let me know where I can help and I will.

[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 https://github.com/faceyspacey/redux-first-router/pull/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!