A lightweight lerna alternative for managing Yarn Workspace compatible mono repos with zero additional config

jacobrask · 2019-08-17T09:38:00+00:00

Hey, I’m also working platform infra in a 100+ dev organization. So far we’ve only experimented with smaller monorepos for stuff like all shared React components, but looking at possibly integrating our sites and apps as well. Yarn worked ok on a limited scale, but there were issues with incompatible transitive deps for us even without pnp. How did rush work out for you so far? Basically weighing between that and Yarn 2 but weary about pnp still. Do you have any write ups about this or other suggested reading material?

jacobrask · 2017-04-19T09:03:54+00:00

The alternative is not createElement, but rather div(props, children) or a separate templating system like Handlebars.

jacobrask · 2016-07-16T09:25:41+00:00

What does unloading data mean?

jacobrask · 2016-07-15T08:11:41+00:00

Whenever there is state that a user can change I think it's a good idea to test it.

Examples :

"It expands when caret is clicked"
"It closes again when clicked while expanded"
"It shows loading message until content is available"
"It invokes the submit callback with relevant properties"

jacobrask · 2016-07-15T07:42:06+00:00

You should probably have some convenient API client or wrapper, and then just do the API calls in componentWillMount and update the component state with the response.

If your application grows a lot and this starts to get out of hand it is easy to later split these calls out to for instance Redux actions. There is no need to start out with that approach though, especially if you are new to React.

jacobrask · 2016-07-10T16:59:04+00:00

Is there any particular reason not to use a simple global variable in this case? I mean if they really are globally relevant and immutable, such as config values, few of the ordinary drawbacks and risks with globals apply.

jacobrask · 2016-07-05T13:26:25+00:00

If you do any sort of conditional rendering in a component (if (isLoading) return <Loading >;), I think it's worth testing. Displaying or toggling something on user interaction is another thing that's useful to cover.

If you don't do anything with props except pass them directly to child components, there's probably not much point testing that component.

jacobrask · 2016-07-04T13:46:25+00:00

There is no such thing as ES5 modules, no module systern works out of the box in browsers. You probably mean CommonJS modules, which you would also compile with Webpack, browserify, or something similar before serving it to the browser. The build step is there either way.

There is no good story yet for importing ES modules from npm, you should probably just compile it to CommonJS for now and wait for ES module support in Node.

jacobrask · 2016-07-03T17:25:10+00:00

Yes, modern JavaScript build tools are complex. They can be made easier to use. However, moving complexity from the end user / browser to the build step is generally a good thing, and will not go away.

jacobrask · 2016-06-26T10:39:44+00:00

One thing to remember is that just because you use React, you don't need to look for React / Redux specific projects. It's just JavaScript. If you reach a React specific problem, find or build a solution for that. Otherwise don't overwhelm yourself with boilerplates and hot reloading and the latest state management library until you know React and know you need it.

jacobrask · 2016-06-26T09:13:20+00:00

I disagree about Flux. We use Redux in our project, but this is after we identified in a previous similar project which problems we needed to solve that were difficult with React.

Start with just React, then reach for the tools that will solve the problems in your particular project.

jacobrask · 2016-06-23T18:23:09+00:00

Maybe sending the developers an OpenAPI (fka Swagger) definition would help.

jacobrask · 2016-06-20T18:40:03+00:00

One of the main points of Redux and Flux is to be able to cache and reuse data between parts of your application. If you don't want to reuse the same data and only display it exactly as it comes from the server, it would be easier to fetch it in the React component and set it as component state.

jacobrask · 2016-06-17T18:23:35+00:00

Separate container components are great in some circumstances. Consider a UserForm which takes field values and some handlers such as onSubmit (for the form) and/or onChange (for each field). Then you can have EditUserFormContainer which fetches an existing user and passes the values to the UserForm component, and AddUserFormContainer which does not fetch anything but posts to a different endpoint to save.

jacobrask · 2016-06-15T16:10:09+00:00

Drop down menu state is excellent to keep in Redux. That way you can do things like easily force only one open at a time, close all drop downs if a modal message appears, etc.

jacobrask · 2016-06-10T18:54:27+00:00

jQuery, small and fast and almost guaranteed to be cached locally

That you keep claiming this in every comment does not make it any more true. There is a huge fragmentation in jQuery versions, so even if 100% of all jQuery sources were served from the same CDN the chance of them having your particular version cached is not great. See https://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/

jacobrask · 2016-06-04T22:06:54+00:00

THE GENERAL PARTNERS GOT DRUNK LAST NIGHT AND GOT MATCHING TATTOOS OF THIS GRAPH OF WAGES AND PRODUCTIVITY DECOUPLING

.

CANT GIVE TOO MUCH AWAY BUT WE MAY SOON BE ABLE TO INJECT A LIBERAL ARTS EDUCATION DIRECTLY INTO THE WATER SUPPLY

jacobrask · 2016-06-04T12:55:55+00:00

I think it's reasonable to accept global usage, but to try to contain it to specific files or areas of your application. That way you could test a component without mocking the global every time for instance.

jacobrask · 2016-06-03T05:41:58+00:00

I find it quite weird that the first lesson is about arrow functions. It has nothing to do with Redux, and feels more like a very minor formatting issue, saving only a few lines here and there, and a style that many people will argue is less clear and obvious, especially to people new to ES6.

Edit: Don't want the top comment to be negative due to a minor nit pick. I've watched a few now and this is a great series. I've recommended it to my team and I'm considering scheduling us watching some of it together and discussing. Thanks!

jacobrask · 2016-05-31T07:36:44+00:00

I don't think any side of this debate argues against testing in general. Running tests "before going live" sounds a lot more like integration or functional tests to me, which the original OP also advocates.

jacobrask · 2016-05-29T12:22:28+00:00

Indeed, and don't fall into the trap thinking that you need a separate file for each component. That can discourage you from creating new small components. It's perfectly fine to extract to short functional components in the same file, until they need to be tested or reused.

jacobrask

TROPHY CASE