for splitting did u ever implement it in the boilerplate? about redux-first-router

[faceyspacey]

here's a little goodie i showed Zack. ultimately im gonna stay in hiding until I release Rudy. I'm only showing u cuz ur putting in energy, and nothing counts more then energy and drive.

That said, i can't waste my time communicating. Priority for me is churning out code. When there are docs--as i wish i always had taken the time to make for u guys--that will change. Then I won't be the only one for whom its productive to stay head down in Rudy code. I admire you for even trudging around in my code and doing any of what u did--very impressive!

So, Zack has a task from me (to make the foundation of the babel plugin based on what @theKashey did here: dai-shi/reactive-react-redux#1 (comment) ).

As far as you, if you wanna help get the docs that would have helped u all this time, build a docs site like the above screenshot. I'm gonna lay out the only set of directions I have time to give in this thread.

Its just a homepage like above and a standard side-bar based documentation site, of which you can essentially use one of countless docs sites as your influence, eg:

• https://jestjs.io/docs/en/getting-started
• https://stripe.com/docs/api/terminal/readers

Here's the influence for the colors and homepage: https://wasmer.io/

I stumbled on that site a few months ago and saved it, knowing that it was exactly what I wanted our homepage to look like. U could even rip their HTML to get things going. The Respond logo i made today.

The docs site needs to essentially translate github markdown into react components. Im just gonna write the docs like github markdown files like before. A future challenge is that such docs will live in multiple repos or locations. So, our docs site will have to maintain an array of repos/folders to extract docs from. The paths of docs files will become sidebar titles, etc. For now, whatever the standard tools are to generate docs from one repo of markdown files is fine. Just keep in mind that down the line we're gonna have to find a way to extract from multiple repos (e.g. Rudy, Remixx, etc).

SIDE NOTE: in the future, we wanna dog-food our own ware and build this in Rudy. ur more than welcome to start that way. It will make it a lot easier to download the docs from multiple repos from our thunks than using some docs site generator. Down the line this site will expand into a business that prints us money. But for now if i was to do it, I'd use a generator that takes a repo/folder of docs as input and lets u stylize the output. That way we can be sure to get something out sooner while devoting time to higher priority things like actual code. And then down the line, when we have time and truly need it, we'd migrate to our own custom Rudy-based setup...U however may wanna use this task as a foray into using Rudy. It certainly will become very self-referential as the docs themselves begin to be produced. Basically it is high value for an internal person other than me to begin putting Rudy to the test, in order to both get familiar with it and stumble upon any issues. Have u used it for anything yet?

Anyway, the plan from 10 months ago is on. Nothing matters except that I finish Rudy. Anything else is extra. I dont have time to converse about hypotheticals. If u take this on, excellent. If ur too busy, all good. This is THE TASK with ur name on it, though. Deadline is the first week in April. Thats my deadline to get Rudy 1.0 out. I knocked out 3 of my old todos from my to do list yesterday. Got one big one im trying to finish today. It's for real now. Hit me in Zack's slack if u wanna talk about the site. Otherwise, just go for it.

If ur not a designer, think of it as a chance to strengthen ur design muscles. We're just rippin other shit and makin a purple docs site. It should look crisp. Jest's is the right structure, but it's styles are weak. Stripe has always been known for a heavily styled beautiful docs site. There are thousands of others worth checking. Do the googling and bring up some of ur favorite docs sites u may remember.

The style for the <code /> element is always key to getting it right. I like bigger and bolder (i.e. fonts). Of course the React docs site styles arent bad, but i have seen more impactful elsewhere. Either way, the stylization is baby stuff. Once we get it up and sucking up .md files into the standard sidebar template + the pretty purple homepage, we can iterate on the styles until they're just perfect.

The logo too is also up for interpretation, but im fine with what i made today. I just wanna move. In fact I have to move, because I have a client with a massive project that needs an overhaul who already uses RFR + Redux, whom i want Respond to come to the rescue for. So this is all real for me. Any help is much appreciated. We'll talk business down the line on how we're gonna take over the world and have Respond be the technology at the tip of everyone's tongue instead of React, redux, graphql and the like. Thats the goal.

There's tens of millions to be made by savages who work full time on this with a business mind. I'm not employed and never have been by a software company. i'm a lemonade stand entrepreneur whose been doing this entirely too long because I got obsessed with code. I know exactly how everyone should be building their apps.

I stopped giving a fuck a year ago when i realized i could end up greatly wasting my time while the React team comes up with what they're doing (i.e. with Hooks + Suspense). Now that I know, i'm more convinced than ever we have something the ecosystem needs!

A little backstory: i spent an entire year building a consistent and awesome OOP interface/wrapper over Meteor. It also solved many long-standing problems. Then React killed meteor and that year went to waste!!! That was a 4 years ago, and i've never forgotten that pain since.

SIDE NOTE: reducing developer pain in one way or another has become my life's work.

Of course when such things happen, u can at least say u grew yourself as a developer--and that's more important than any project (I always say YOU ARE YOUR GREATEST PROJECT)--but at this stage of my life I couldn't waste time building something the world doesn't need again, and therefore doesn't make me money to survive/thrive.

Anyway, Hooks + Suspense doesn't solve the real needs of serious apps. The best you can do with that stuff is build the Facebook (or gmail) chat message widget u see on their desktop apps (notice how it can be on any page and doesnt need a URL, and it's pretty small visually + isolated).

Basically it's for small widgets, and the guys at Facebook don't realize this because they spend too much time self-promoting on social media and thinking everything they touch is greater than it is. It's like they have never built a serious sized app and seen how much data-fetching needs real apps have, and how important routing is. Facebook after all basically has no routing, it's a private site.

There's a lot of glaring holes in their approach and their experience. Simply put, those guys don't know the pains of real day-to-day developers. They seem to be absorbed in an echo chamber of learners that just need to be able to do the increment/decrement app via the most natural paradigm.

As a result those guys have led this ecosystem into destruction. I wanna like Hooks and suspense, but the only thing that provides any value to the Respond Architecture is time-slicing (i.e. so we can have smooth animations). The rest will continue to lead developers down the pit of failure that is micro-focused modular components.

Their system is modular--and that's their whole guiding light, which is a very good thing; the spot-on thing to focus on--but it's modular at too micro of a level.

• Respond lets u think in terms of modular mini apps.
• Respond lets u group side-effects that would otherwise conflict across many levels of your component tree into a natural linear pipeline (aka our route primitive)

U r probably one of the only few on planet earth that understand these things. I assume at least--or u wouldnt be working on this stuff with Zack.

Components--no matter how hard the React team tries to force that square peg into a round hole--will never attain that level of seamless orchestration.

That the <Suspense /> component can capture such work while it's loading is a neat trick, but no cigar. Their wishful thinking that they could take the pure function rendering paradigm and turn it into something specialized for components and hit these concerns is exactly that: WISHFUL THINKING.

Wishful thinking happens to the best of us when we get absorbed in code and can no longer see the forrest for the trees. It's why I took a year off from React. Even if it turns out pretty decent, some how, some way, there's a massive opportunity for another paradigm such as ours (which by the way is simply the old PHP/Rails paradigm) to do extremely well. More than likely--if and only if enough of us can put in the work--we can dominate and overcome even a marketing force as powerful as the Facebook developer machine.

Innovation always happens at the edge--if there's one thing i learned from my forays into open source, it's that u cant do this for recognition. That's not something u can count on in the least. U gotta do this for ur own growth + money. U cant count on the legions of magpie developer to give a fuck when they dont have the skills or experience to do anything but follow the biggest authority (e.g. Facebook) like lemmings.

They say dont hate the player, hate the game. What I say is hate yourself for playing the wrong game.

Anyway, i'm only back cuz i built a bundle of goodness that was ultimately my greatest work and I got someone who could greatly benefit from it who is willing to pay for it. Straight talk. I'd otherwise remain in Haskellandia doing stuff in Elm or PureScript.

If we can leverage that into something that benefits all, and makes the inner circle even more money, then lets fucking do it. There's no bullshit in the way i operate. No humblebrag corporate authority i gotta protect. None of that. I work for no one (other than clients of my highly particular choosing). And I will help u 2 do the same. And then we'll achieve the most important goal:

• making a product-based business

See, here's the hiearchy:

• employment (ur a slave and a company [and its founders} profits greatly off ur back; u have minimal control over ur life)
• service-based business, aka contracting (pick and choose clients/projects)
• products-based business (each client is the equivalent of one of millions of customers buying a $1 coke from you, therefore nobody owns u, and u can truly focus on building systems, specifically systems that print money while u sleep)

So that's the philosophy. Thats why we do this. Im 33. Since I was 19 i've been single-handedly building entire apps soup to nuts (full stack and beyond). My peers have left to make millions via startups, doing Machine Learning + Crypto. I'm only still in this cuz of my devotion to the craft, the value I place on human interaction with interfaces, and the perfection of my self and the vision i somehow have always been blessed with in the UI space.

So im doing what my destiny is. Simple as that. This time I'm determined that the merit of my work is enough to overcome a sea of false influencers. Yes, to win over the hoards of magpie developers, even in the face of the Facebook developer goliath.

---

now this is why i wont be communicating. i prefer to slaughter code. we'll do a video chat sometime to get to know each other. im not one of those people who has digital friends. when it comes to code im a lone wolf, and all my friends and human interaction happens outside of computers (funnily enough with people who dont know the first thing about computers). Open source isn't my "dorky family" as another unnamed developer who goes by the same first name as me and who also built a very popular component code splitting library might say 😈

there's opportunities ahead. i can help u get rich and attain the freedom u seek. if u choose to build this docs site, that will be my cue to know what opportunities I can pass ur way. Contact me on Zack's slack if absolutely need be. Otherwise see u when it's done. We'll video chat then. Trust yourself.

[faceyspacey]

ps, here's a gist from way back when of the sort of things that must be addressed from the middleware's perspective:

https://gist.github.com/faceyspacey/be2ea05eb69de705f9da61c6b236f08a

[faceyspacey]

ok here it is:

https://github.com/ScriptedAlchemy/redux-first-router/blob/rudy-respond-prefetch-codesplit/examples/boilerplate/src/routes.js

is that the farthest u got with it?

[hedgepigdaniel]

When you say splitting... which splitting do you mean?

[hedgepigdaniel]

If you mean reducer code splitting, once respond-framework/rudy#17 is merged in rudy, you can do something like:

connectRoutes({
  SOME_ROUTE: {
    injectReducers: (dispatch, getState, { bag: { injectReducers } }) => {
      return import('../reducers/thisRoute').then((reducers) => injectReducers(reducers));
    },
  },
}, [
  // ... usual middlewares
  call('injectReducers', { runOnServer: true, runOnHydrate: true }),
  // ... more middlewares
]);

I like this because it preserves the purely functional nature of the component tree - reducer injection being a procedural, controller-like concern I think it should be done in the controller. That PR is a simple feature so that you can use the call middleware to run something during SSR and hydrate, which you need for reducer injection.

Gonna be honest, I haven't actually tried it but I mean to soon :)

[hedgepigdaniel]

Just occurred to me that we can use the same thing to do ADD_ROUTES in SSR

[faceyspacey]

Daniel, so I'm implementing this all for a client NOW. What I left 10 months ago must all come to life immediately lol.

The plan is/was:

• code split components are stored in state, and rendered from there, eg:

<RudySplitRoute path='/settings' componentName='Settings'} />
<RudySplitRoute path='/dash' componentName='Dashboard'} />
<RudySplitRoute type='NOTIFICATIONS' componentName='Notifications'} />

so obviously, our store would have this store.getState().location.components.Notifications, which in this case our RudySplitRoute component is programmed to access (while showing a loading indicator if the path matches but the component has yet to load)

• reducers are injected immediately, and are insured to receive the route change action + possible follow-up async response action. Redux doesn't support this without unnecessary additional actions called by replaceReducer. So Im gonna fork Redux and make it operate the way I want it to....One of the principles of Rudy is "less actions, fat smarter reducers." Most companies are using Redux incorrectly as one big mutable setter/getter store. Really, what u want is the least amount of actions as possible, and a small number of very "fat" reducers that listen to a diverse (but not duplicate) set of actions ur app throws at it.

• other async utilities can in fact be tacked on to the route before completion. aka the route can be "built while the plane is flying"

---

Awesome seeing ur example of the Rudy middleware pipeline by the way!! call('injectReducers', { runOnServer: true, runOnHydrate: true }),

Yea, basically, something like that, but part of a comprehensive middleware that automatically splits all things u might need (reducers, components, sideEffects, misc). The key is making sure the reducers are injected at just the right time, and if they're late, we gotta either dispatch the action again, or--if we wanna fork Redux and optimize it--we call the reducer independently once with the latest action, and attach the resulting state to the greater state object. This idea that Redux is this function we can dispatch a million actions to, having all the code run over and over, is played out. For this case, a few tweaks to the Redux lib is quick and painless, but perhaps we expand the concept to more things later

At least until Suspense is out, unecessarily executed code is the difference between whether ur animated app has jank or not. A lot of people in the industry don't really know much about React's pain points with perf because they build glorified "websites," not real animated "apps." We've always been about apps in what we're doing. U gotta be able to build Uber's app with Respond Framework. U gotta be able to build the next billion dollar unicorn with our tools.

[hedgepigdaniel]

I'm not clear on why redux needs to be forked - given that Rudy already has an async middleware pipeline (which delays the dispatch/commit of the action to the reducers), isn't that enough? e.g. if the call('injectReducers') is before commit, then the action won't be dispatched to the reducers until the reducers have been updated.

[faceyspacey]

https://github.com/reduxjs/redux/blob/9c0b74192348fd10b66b44f39bf659d4125164f2/src/createStore.js#L239

we dont like that extra dispatch there.

[hedgepigdaniel]

I see code splitting and preloading as basically having three facets, corresponding to the M, V and C.
For code splitting the initial load:

• M: reducer code splitting (which I think can be done quite simply with the call middleware or a more specific version of it)
• C: controller code splitting (which can be done similarly by wrapping thunk and other route callbacks in an async import)
• V: component code splitting, which is handled by RUC and WFL

For preloading based on a routing action:

• M: no real change, just run the callback to inject reducers but don't dispatch the action to the reducers or run any other callbacks
• C: You could split the callbacks into a loadCallbackCode and executeCallback stage, and similarly run loadCallbackCode but not executeCallback on a preload action
• V: This is a bit harder, because by its nature the controller which is doing the preloading ideally does not know or care about the component tree, and probably more importantly vice versa, the component tree doesn't need to know anything about the controller - App = f(State).

So I think while RUC and WFL handle code splitting pretty much ideally in the initial load, SPA transitions and preloading, not so much. Imagine that one each route you have not just one, but a whole tree of code split components. The exact set of components needed to render a route depends on the route parameters, and also the rest of the application state. RUC/WFL handles this just fine on the initial load, but on subsequent transitions it will create jank because the top of the tree will render before it knows what child code split components need to be loaded. If there is a tree of code split components of depth 4, there will be 5 layout changes instead of just one.

The thing is, is route.components going to be a hard coded list of all the components used in the view? Will users have to update that list every time they decide to code split another component? What if the application logic changes and the list becomes out of date - will it keep preloading unnecessary components and failing to load the right ones?

Alternative idea - what if there is a server side helper for this:

app.use('/codesplit', (req, res, next) => {
  // basically the app requests `/codesplit/<path-in-app>`

  // Chop off the `codesplit` prefix and configure the store according to the initial app URL
  const store = configureStore(req.url.slice(`/codesplit`.length));

  // Render the app, to work out what view chunks are needed for that route
  ReactDom.renderToString(<App />);

  // We don't want the rendered result, but the list of chunks needed to render that route
  res({
    chunkNames: flushChunkNames()
  });
});

So then the component preloading stage can be something along the lines of

// this goes in middlewares - runs before the commit to avoid jank, and runs only on client side transitions
call('preloadComponents', { runOnHydrate: false, runOnServer: false })

// options or the root route:
{
  preloadComponents: async (dispatch, getState, { action }) => {
    // Call the server side to determine what chunks we'll need
    const { chunkNames } = await fetch(`/codesplit${actionToPath(action)}`);

    // put the chunks on the page
    chunkNames.forEach((chunkName) => {
      document.getElementsByTagName('head')[0].append(`<script src="/chunks/${chunkName}.js" />`);
    });

    // Now when we actually transition to the route, all the required modules will be available synchronously :)
  },
}

Its a bit wasteful of server resources, but it means that the client can have full preloading of all code needed for a route, without having to mix up the concerns of the controller and view. There is no hard coding in routesMap of which components will appear, and no hardcoding in components of which route they expect to be rendered on.

[hedgepigdaniel]

Interesting - I see the dispatch, but I'm not sure why its a problem?

reducers are injected immediately, and are insured to receive the route change action + possible follow-up async response action. Redux doesn't support this without unnecessary additional actions called by replaceReducer

The rudy middleware API already does this though, as I understand it - redux actions are intercepted by the rudy middleware and don't reach the reducers until after all the rudy middlewares before commit have run. If one of the middlewares, e.g. injectReducers does an async import and replaces the reducer, then that should be fine - the original action will only reach the reducers after the reducer has been replaced.

[hedgepigdaniel]

Or more specifically - these internal redux actions might be dispatched before the reducer is replaced - but what is the significance of that?

[faceyspacey]

what i had in mind was a script or even babel-plugin that parses your code, producing a flat list of your routes and their dependent chunks (i.e. the name of the module that can be dynamically imported in order to fetch a given chunk). It's basically the same as your server-side method, but done once as part of your build process and always automatically kept up to date as a result, and no wasting of server resources :)

Basically your routesMap is static, so all the deps should be statically discoverable, and not require actual renderings to discover.

Perhaps its easier said than done, but maintaining that array of arrays manually in a first release of these capabilities is fine by me. It's a key/val on each route; so yea hard-coding in your routesMap these deps is the initial plan. Not the end of the world.

---

regarding the reducer replacement, there's scenarios where--if perf wasnt an issue--u just really want to apply the new state key/val without dispatching an action. i cant recall right now.

[hedgepigdaniel]

haha, every time I come back to read/respond to your comments they grow to at least twice the size lol

Basically your routesMap is static, so all the deps should be statically discoverable, and not require actual renderings to discover.

I guess that's the limitation. Something which wouldn't be possible with that is e.g.

const UserFeedView = ({ userHasEnteredBeta }) => {
  if (userHasEnteredBeta) {
    return <UserFeedViewBetaAsync />;
  }
  return <UserFeedViewLegacyAsync />;
}

const ConnectedUserFeedView = connect((state) => ({
  userHasEnteredBeta: selectUserBetaChoice(state),
}), UserFeedView);

Or at least not unless you redirected to different URLs depending on whether the user had signed up for the beta. There could be also be other conditionally loaded components that depend on the application state and are not determined by the route action type. e.g. a unread messages preview that only appears if you have unread messages.

I guess requiring that the set of async components is determined by the route type is not the end of the world, and covers 80% of code splitting - at least you don't need to load entire unrelated pages, just all the possibilities within a certain section of the app. It means the user has to be careful about which components they enable code splitting for if they want to avoid jank.

Perhaps its easier said than done, but maintaining that array of arrays manually in a first release of these capabilities is fine by me. It's a key/val on each route; so yea hard-coding in your routesMap these deps is the initial plan. Not the end of the world.

That seems like a good basic capability to start with. I think all that is necessary for that from our side is the call middleware. If the user has to manually maintain the list of modules/chunks that need to be imported, they may aswell write the import code themselves, e.g.

const routes = {
  FEED: {
    preloadChunks: (dispatch, getState, api) =>
      import('../preload/module-which-imports-all-that-is-needed-for-feed-route');
  }
}

That's also quite flexible, in that if they want to support more advanced use cases (e.g. loading user generated content pages that contain a large library of (dynamically) embedded widgets (each of which is code split) then they are free to do that too:

const routes = {
  USER_GENERATED_PAGE: {
    preloadChunks: (dispatch, getState, { action: { params: { pageId } } }) =>
      api.get('getWidgetsUsedOnPage', { pageId})
        .then((usedWidgets) => Promise.all(usedWidgets.map(
          (widgetId) => import(hardCodedMapFromWidgetIdToModule[widgetId])
        ))
    )
  }
}

[hedgepigdaniel]

Thanks for sharing all that, interesting stuff :)

A little backstory: i spent an entire year building a consistent and awesome OOP interface/wrapper over Meteor. It also solved many long-standing problems. Then React killed meteor and that year went to waste!!! That was a 4 years ago, and i've never forgotten that pain since.

Damn, that must hurt. I'm fairly sure that in the near future the React ecosystem isn't going anywhere, and there aren't many projects in it that have realised the value of an MVC architecture and truly functional components.

There's lots of problems that rudy as is solves, the big one being the async call middleware. My thinking is that we should polish the current feature set and get rudy released with confidence as soon as possible, because it already solves real problems that people are facing today. The more of those problems we solve, the more the ecosystem will rally around us and help us to solve the next big problem. If I'm honest, nested routes strikes me as that kind of problem - a big change that needs significant breaking changes (probably bigger breaking changes than RFR -> Rudy today) and which solves an entirely new/additional problem to what is already solved by Rudy. Something that should go into Rudy 2.0, so that we give ourselves time to do it right and still get the existing feature set polished, documented, and released.

If I can get this pesky CI issue fixed we can merge respond-framework/rudy#17, and at that point it will be possible to do code splitting of M, V and C, with the preloading part a very doable follow up feature without much code changes (just a preload key in actions or something).

Re the docs site, I'll try and find some time to start that. I have built a couple of small projects with rudy and it generally works well. There were a few simple bugs when I started working on it, and lots of DX issues, and I know about a couple more existing minor bugs which I mean to fix soon. But the core of it is solid - it works. I'm sure it will work great to build a docs site. react-static might also be a good option - the advantage being that it only requires static hosting, vs a rudy app which will need more advanced hosting setup. Maybe there is also something more off the shelf for documentation specifically.

The logo too is also up for interpretation, but im fine with what i made today.

Looks nice! What about the helmet - do you see that as the rudy logo as opposed to the respond framework logo, or is this a replacement for both?

[theKashey]

@hedgepigdaniel - you are in Sydney? How I wish to talk with someone about Rudy, cos I've lost a track... long time ago to be honest :)

@faceyspacey - and my wife could help make your promo page real. That's her profession.

[hedgepigdaniel]

I am yes! HMU on Zack's slack, lets meet up and have a chat

[faceyspacey]

@hedgepigdaniel the intention has always been u can provide an array or a function.

So ur example is simply done via a conditional function at the route level, eg:

route.load = request => ['MyComponent', request.state.beta ? 'Beta' : 'Regular']

CON: you gotta maintain it and keep it in sync with the chunks you actually have, but that's not a case of "appeasing Respond"--rather, it's the only natural way to make the given chunk's capabilities available. U will easily know that it didn't work, for example, when a dynamically loaded component is not showing on the page. EG: something like this will just show the loading indicator indefinitely:

<RudySplitRoute path='/beta' componentName='Beta'} />

...and yea, in the first release, u cant provide the paths of modules, u gotta manually write the import() code like u did. We got this fam.

[faceyspacey]

@hedgepigdaniel yea, rudy will keep its logo. it might not be known for long unfortunately, because the overall plan is to not complicate things for people by having too many repos to worry about. Respond will be the flag we are waving going forward. So possibly too bad for Rudy, but then again that depends on how much time between the launch of Rudy and Respond. But once Respond is out, we're gonna keep the internals somewhat hidden so we can easily onboard people to a simple Raislesque interface.

Regarding nested routes, my guess is i can get it done in a week maximum. Probably 4 days. But it's a big change. I dont wanna deal with a big 1.0 to 2.0. I want this one and done. We got so many more fish to fry. Lots of other things. Im done with routing after this for a long time. Only bug fixes, not features. That's the ideal. Or u know, small features. But not "big features." We got many BIG THINGS to build like super advanced action-packed DEV TOOLS. GraphQL/Apollo Middleware. StackNavigators. A monolithic learning playground + interactive tutorial like CodeCademy/KhanAcademy. React has all these people making learning materials. Really, what's needed is one de facto learning center that really nails it. Respond at its peak will have a core semi-internal learning playground + set of tutorials. I wanna build tools to help people make tutorials. So a specialized tutorial-maker, which itself is built in Respond.

See, once Respond is done, building the DevTools, TutorialMaker, or anything is gonna be done at 7x the speed of traditional React tools (which itself is like 6x the speed of the old mutable jQuery way of building apps). None of this changes how much time we spend building apps unfortunately, since application expectations are ever higher--i.e. we're nevertheless spending even more time building the apps du jour.

---

Regarding those bugs, there's a lot of commits. Ultimately bro, u might not wanna hear it, but im working on my old codebase (the code prior to even Zack's work on Flow types). For 2 reasons:

• it's easier for me to get immediately productive
• i gotta be sure no bugs were introduced

Now that said, can you send me links to the commits related to my bugs which you found.

Consider what u've done as time well spent learning a large codebase. It wasn't a waste at all. I'll incorporate all application fixes into my code. Send me the links to the shas so im aware of them.

As far as Workspaces + Lerna, we'll address that once Remixx comes into play. Basically, i think it will make sense implementing higher up the stack. Cuz we're gonna have Rudy, Remixx, and several other things at that level.

Anyway, that sorta of stuff will be subject to change and final decision-making will occur when we go from Rudy to Respond. For now, it's just Rudy, and I don't want multiple repos until this is rock solid and being used. I dont have time for that. Application code is what it's about until then.

As far as anything u've currently been working on for Rudy, my recommendation is to stop and take that time and put into the docs site. Im working on this full time. Just get me the shas u feel strongly i should incorporate and I'll do it within my original organization structure.

Also, April 1st may be too long for those docs. I'm almost done with everything I had in mind besides nested routes, and my client needs these docs. I aim to have the docs for them mid-week next week. So by the following week, there's no reason I can't make em look pretty with a docs site. There are doc generators. All these codebases use em. Checkout what Jest and React use.

And as per ur suggestion, nested routes will be postponed to some degree. Basically, we're at 0.0.1. But by 1.0 the goal is to have nested routes. So similar to waiting until a 2.0, but sooner. In short, the 0.0 is for industrious individuals like yourself, but I wont have the time to safe-guard people from changes between 0.0 and 1.0. Nested routes will be done before the big marketing push of the 1.0.

[hedgepigdaniel]

Regarding those bugs, there's a lot of commits. Ultimately bro, u might not wanna hear it, but im working on my old codebase (the code prior to even Zack's work on Flow types). For 2 reasons:

* it's easier for me to get immediately productive

* i gotta be sure no bugs were introduced

I gotta say, I think you are putting a bit too much emphasis on you and what you want, vs everybody else, and not giving enough credit to others for what they have done.

I'm a little bit tired of hearing that the next big thing you want done will be done in "1-2 weeks tops" and we just have to wait a couple of days before we can release the mountain of new features that are already implemented. It doesn't make any sense that you are happy to disappear for a year (without giving commit access for redux-first-router to anyone else) but then claim that nobody can release any of the new features which are already implemented because you want to be burdened with the responsibility of supporting a release. There is actually a community of people around these projects which are willing and able to improve them. They are prevented from doing so by your practice of developing everything in an environment which is totally inaccessible to everyone else, and claiming that its not ready yet and you're about to finish it, even when you must know that that isn't the case.

I find it pretty patronizing that you imply that my (and others) only contribution is "time well spent learning a large codebase". Most of the time I've spent I've spent cleaning up the repository so that it is somewhat convenient to work with. There are some now unit tests (as opposed to integration tests) so that when they fail its actually clear what the problem is (and no global random number generator hacks). There is CI (notwithstanding the current bug) which has ensured that we don't merge regressions. There is a example in the form of the boilerplate, which actually works. And when it crashes, it prints source mapped stack traces. The <Link /> component also works (this was an obvious mistake, but one of many lost in hundreds of eslint errors). I'm apprehensive about implementing nested routes because the only good reason to do it is to get your blessing to do a release. It's crazy to implement a huge breaking change when there is such a huge mountain of unreleased features (which people are sorely missing) that haven't had any validation and testing by the wider community.

It's not just code - @ScriptedAlchemy has been instrumental in making space for the project to be developed in your absence. Quite a few people have offered to help and submitted PRs in that time. Nested routes is closer to fruition now that there is a somewhat specific plan that you and I sketched out together (respond-framework/rudy#3). respond-framework/rudy#17 (A solution which I sketched out with @toerndev) makes it possible (in a very simple way) to code split reducers, which is something it seems you weren't particularly clear on how to do. Various people have contributed to documentation and examples.

So no, if you don't have time to check out the master branch and try to work out specifically what bugs you imagine have been introduced, I don't have time to submit to your "organisational structure" and spruik my commits to you one by one just because you didn't feel like engaging at the time with the PRs that I made and had reviewed by others.

I would suggest if you want to work together in a productive way with me and Zack and the rest of the community, that you branch off master, make a PR and submit it for review. If I've introduced bugs, I'll happily fix them, but you'll need to find them first. Otherwise, as always, all of this code is open source and you don't owe anyone anything by virtue of having written most of it. You're welcome to work on your own fork/branch and do your own thing, but don't expect me to follow you around and do your dirty work because you promise to make me rich and give me freedom.

[faceyspacey]

Why havent u released anything? You could have done anything all this time. Nobody was stopping you. We all know the nature of open source and forks. I assume you know I don't need this explanation.

It's been roughly 8 months since you started committing. You're gonna have to face the realities of the fact that you don't have enough time to work on this. I clocked 8-10 triple full time months on this on Rudy. And that's after however much time on RFR the year prior. I'm pretty sure I've still clocked somewhere on the order of 10-100x more time than anyone on this. I do regret coming off in any way arrogant and unpleasant. But at the same time, i made myself clear from the start how uneasy I was with all the reorganization. I understand it might have been a good way to get familiar with the code, but it leaves me stranded. I would have preferred had you really try to grok the code before making assumptions on what it needs organization wise. This isn't wasn't a collab. It was one man's work for a very long time. So it should be obvious that it's far from a productive idea to completely reorganize his work if there were ever hopes that he would come back.

As far as community, and people's needs, I think ur in the clouds. Everything in this game is earned. If they truly have the needs they can do more. You are in the clouds because you think a lot has been done. It hasn't. Go fork it, you're going to be wasting your time. Nobody's stopping you. It's now the stupidest thing to do now that the creator of it all is here and able to devote triple full time to it. But be my guest.

I understand the feeling that u feel like i should examine ur work more. I totally do. And I have. And I will continue to do so. That's precisely why asking u to link me shas! But please understand I need this up and running now, in a format I can work best in. For a paying client, as i mentioned. Working in a codebase that is quite different than what I left is simply not a possibility for me right now.

And by the way, truth is I know more than anyone what it feels like not getting the recognition you feel you deserve. It's something I've come to grips with. All u can do is storm the castle and take it. It's life. Fork away or get in tune with me. Its really ur call...RFR was/is the shit and the main react influencers paid it no mine. RUC cracked the problem of combination SSR + Splitting, and look, both these repos dont even have 1.5 stars. Nobody's written articles on it even. Like a few people who do that sorta thing did that in the beginning, but ZERO OF OUR POWER USERS. Where's ur articles on it? Where's all this contribution. Maybe my expectations are too high--and damn right they are, i have expectations for myself and those around me--but just look around at other repos. RFR and RUC aren't dripping in contribution. It is what it is. I came to except all the reasons why. My faults, and the nature of the industry/community. All of it. The fact that it was in 0.0.-rudy/next for so long, and that I'm a perfectionist and moved on to Rudy proper, and kept adding features. I dont care. I dont need to correct myself for anyone. I've proved I can ship. Even tho RFR/RUC didnt reach my expectations, lots of famous companies use em to great success. So rest assured when I ship this time, it's gonna be on, especially after how underappreciated I was by the influencers that could have made these things pop off.

I'll reward anyone with merit. that's all its about. im highly competitive. if u wanna outdo me, great, i can focus on other things. See, i dont do startups or software that i know other people will do. There's no point. I'm capable of surviving and making bread. I do what other people wont do. Here's what im saying: if u have tracked Techcrunch as long as i have (and the startup community in general), u know most people are more concerned about finding something that hasnt been done yet to line their pockets. The way I think however is this: if this problem is likely solved by someone else in the future, theres not point in me doing it, im gonna do something im uniquely positioned to be one of the only people in the world to do; on top of that, whatever it is, i best grow myself internally/skill-wise tremendously as result; lining my pockets comes second.

That's all to say, if u or anyone else is gonna do it, please prove it to me, because then I'll use it and build further up the stack, or do completely different things.

So u dont know me. I dont know u. Im sure after this hump--well rather, there is simply a strong possibility--that we become great collaborators. That said, somewhere ur gonna have to realize there's a great difference between someone now working on this 15 hours per day, 7 days per week, and someone working on it 5-10 hours per week while they work a full time job. If u wanna do this full time, i'll buy u a plane ticket to San Diego and let's rock it. Or, fuck it, i'll come to u, if ur really bringing it.

In short, we're talking 2 totally different things. Ur gonna have to deal with this with in urself. Im not gonna sugar code it. U may not wanna accept it, and u may hate me as a result. Im a guy that knows what he wants, knows what he's capable of, have crafted my life to be exactly how i want it in the face of tons of adversity, have shipped countless things. On top of that, im pretty sure ive clocked something on the order of 1000x more time on Rudy than anyone, still after all this time! So if u wanna buck heads like rams LETS FUCKING DO IT.

Otherwise, people can continue waiting. Waiters can wait their whole life. I cant even believe ur bringing up stuff like that. This conversation is so typical, and doesnt need to happen. All this code has been here for a year for them to get value out of. Basically if it wasnt for u, nobody would even know how much value is here. They wouldnt bother analyzing the code. People DONT EVEN KNOW. Im not even sure how MUCH U KNOW. U know from hearsay that it can do various features, from stuff me or zack wrote. Maybe u know more, but this is definitely the case for everyone else. INDIRECT HEARSAY. So ur explaining to me how people are now whining over what we promised them. ha. lol. They dont even know for themselves it exists or in what form it exists. As with everything, its on a spectrum--if they were on the furthest positive end of the spectrum, they or someone would have forked it, solved anything remaining and released it.

So calm ur emotions down and get with me to make this great. Or at least, stay out of my way, cuz conversations like this are exactly what i am avoiding.

7.5 months since u started. Most of the work is chores! Which I warned about from the jump as something i was uneasy about and ultimately didnt want. Paste me shas with the biggest changes to actual application code, like i was simply asking. Thats how we get productive--help me see the most valuable stuff u added so we can have conversations about code.

[faceyspacey]

It doesn't make any sense that you are happy to disappear for a year (without giving commit access for redux-first-router to anyone else) but then claim that nobody can release any of the new features which are already implemented because you want to be burdened with the responsibility of supporting a release.

Zack has had access. Not sure what ur talkin about. Yea, Rudy, what are u even talkin about, ur gonna release it. There still plenty of things wrong with it that i never told anyone. Stuff thats been in my spreadsheet of to dos that nobody else besides me has seen. Ur getting far ahead of urself. Yea, im not releasing shit. It's my work, and I wont let it fall flat. Again, this stuff shouldnt need explanation.

[faceyspacey]

I'm apprehensive about implementing nested routes because the only good reason to do it is to get your blessing to do a release. It's crazy to implement a huge breaking change when there is such a huge mountain of unreleased features (which people are sorely missing) that haven't had any validation and testing by the wider community.

It shouldnt be huge. The fact that it's "huge" is a problem, and u shouldnt be releasing stuff this serious. This isnt huge for me. It will be done when I get to it. It was a test from me to u guys to see--like i said--if u are worthy of my blessing. Dont like it, again, fork it, and go find out the hard way. What can I tell u. Attain some clarity for yourself based on the words Im taking the time to share. Im going back over ur message as many times as necessary to show u that IM LISTENING TO U and what I think. U aint gonna get this sort of devotion anywhere else.

[faceyspacey]

I would suggest if you want to work together in a productive way with me and Zack and the rest of the community, that you branch off master, make a PR and submit it for review.

I can't wait for the day when there's enough of knowledge spread across enough developers for this to be our process!

Democracies are earned. This conversation--again--is so typical of open source. Please, let's not let the Respond community be typical!

So u couldnt even do nested routes for me. Show some respect son.

I understand if ur too busy, i understand that life gets in the way. But nothing I'm seeing is entitling you to this holier than thou attitude like u have done so much. And from my understanding u've been paid to do some of this. I never directly received a cent, except from one guy that paypaled me!

So again, its 99% chores i didnt even want happening. U added very few unit tests, and there's a good chance they end up not being needed. If u understand the system, its built primarily of pure functions, and a test runner (createTest) that pipelines through the code in a highly slick way that very quite possibly precludes the need for unit tests (u know the unit tests u hear all the React influencers demoting in favor of integration tests). Unit tests can be extra weight. Im not saying thats definitely the case. Im just saying this system operates in a unique way, where it's far lower priority than most--it's a system heavily based on integration tests; this is intentional, and it worked well for me over the almost 2 years of work on RFR/Rudy. As far as Link, that was never upgraded to work with Rudy. I at least made that clear to Zack. I will be learning from fixes u make to finalize it. But that said, this is one of the things for which ur missing information for. There's a slightly new vision here from the RFR days.

---

As I said, getting on the phone will change things. Emotion and true intention dont translate well over text. We really shouldnt be having this conversation until we at least get to know each other (like Zack and I did). That this is happening is in full part my bad. I shoulda known better. I wish now I just stayed silent and did what I had to do, instead of trying to eek out some project requirements (the docs site) before getting to know you. So totally my bad for that. I hate excuses, but my excuse is I'm now under the gun to deliver all this for a client. For better or for worse, I chose this route as I knew it would force me to complete all this once and for all. I also had no idea how devoted to the cause you considered yourself. Without seeing the one thing i requested, it's hard to tell. And by the way, Im thankful anyone gives a fuck. Outside of Zack, my perception through the txt of issues and PRs was that a few people loved it, a few had some bugs they fixed themselves, but nobody was seriously devoted to its expansion. And I can only base that on my definition of devotion.

Anyway, just know there are things ur unaware of about this codebase. I planned to share more information once I at least saw the first step I requested: NESTED ROUTES. Since I never saw that, it hasn't made sense to me to unleash the flood gates of information about this project. Period. YOU DONT KNOW WHAT YOU DONT KNOW.

[hedgepigdaniel]

I know that you've written 99% of what's in Rudy, nobody disputes that. I'm not here to try and "outdo" you or anyone else. I definitely don't hate you, and I'm always keen to chat. I value the technical discussions we've had, I can see that you have considered my thoughts and I hope that continues. I don't want to fork. I'd much prefer to work with you and have your support.

I haven't claimed to be working full time on this, or that I will get anything done at any particular time. There is nothing that I need to face in that regard that I'm not aware of. I've put in a bit of time when I've felt like it.

Yes, most of my commits have been chores. Besides being a safer way to get started on a large codebase with little documentation, that's because in my opinion the chores were the most urgent missing thing in the codebase. The features are already revolutionary and they work (I know this not from hearsay because I have tried it). There might be some bugs but the basic things work. If there are bugs, IMO the priority should be fixing them, not building big new features. The main issue is that nobody has confidently released it, made a post backing it up to the tune of "This works, I understand it, it does x, y, and z, and I intend to fix any bugs you find". Part of that is because the codebase was such a mess (not in terms of overall design but in terms of documentation, developer experience, tests, tools, etc) - and therefore nobody could truthfully say that that except the original author. I think it would be a really positive step from you to give contributors a bit of freedom. If you won't even accept simple build/DX improvements, why should anyone believe you will accept big breaking changes?

I know that nested routes was "a test" - you made that very clear. The thing is, I'm not hear to pass your tests. I want to use Rudy for bigger projects and I want there to be an active community around it so that other people use it and it actually fulfills its goal (as I see it) of improving the react ecosystem. For me, keeping the code in an impenetrable state and not making any releases for years is not a good way to fulfill that goal. There have been a lot more PRs and general help in the last few months because thanks to the efforts of Zack and I, it looked like the project was somewhat maintained, and some people thought it was worth their time working on it. It worries me now that they will change their mind, because they will see that even after their PR is merged you will ignore it and fork from before, because apparently nobody else's work is good enough for you unless they do exactly what you want.

Let's be honest, you have made it very clear that you don't want rudy to be released until at least nested routes is done and various other things you've asked for - so that's the main reason nobody has released it - because we are all waiting for you. Now you're telling me that until I do nested routes, I won't even have the privilege of hearing what your goals are for the project, or see a list of bugs that you already know about. I don't think that's a good way of working together. If you have goals for the project and you want help, make your goals clear. If you open a PR and you are the the only expert on whats in it, fine. Reviewing a PR doesn't mean you know better than the author. We can have a discussion about what it is and what its for and we will all be better off.

[faceyspacey]

That time of the nested routes assignment has passed.

Yea, i think there was 2 other things in that batch, but that was the main near-singular thing I wanted to see. Zack wrestled TypeScript out of the equation. If u wanna release under names I own, and generally have my cosign/backing, I don't view my request as unreasonable.

Now, with me back working full time to complete a vision, it's a different tune altogether. The nested routes assignment is off the table. Goals etc likely will be posted in roadmap.md--in other words, it's a non-issue. Most importantly, it's not time for community engagement between me and any but the most devoted (in terms of time that can be provided). If that's you, great. If not, also fine. The reality is that this is the only way I can ship, that it will be shipped--because I can only work the way I know works for me, and by which I have successfully shipped OSS in the past. After launch, the following stages require different more community-centric behavior; this is essentially a brand new thing, intended for release in a very specific way, and since it wasnt launched in my absence, im not gonna let it be--in my view--diluted now that im back. By the very nature of things, the ball has been passed back to me to launch the way I see fit.

In general, we're getting ahead of ourselves. Let's talk again when I give the signal that some goodies are available. I'll go through all ur commits (and branches) thoroughly. At least let me know what branches to check out.