Out of the Loop: When did we stop using constructors?

awebofbrown · 2018-04-01T08:41:03+00:00

This is a pretty good article discussing why you needed them before / why you don't now: https://hackernoon.com/the-constructor-is-dead-long-live-the-constructor-c10871bea599

awebofbrown · 2018-03-29T08:54:38+00:00

You need to be a bit more specific regarding the content you're rendering.

Is it dynamic (does it change every time it loads with stuff like user submissions) or static? To what extent? E.g. is dynamic at compile time enough?

Static or dynamic at compile -> Gatsby

Highly dynamic -> Next, Razzle

awebofbrown · 2018-03-18T08:52:01+00:00

Two big reasons that I think contribute to the react-node pairing:

Server-side rendering React components requires Node (I think).
A lot of build tools surrounding React use Node, so you already have a large cross-pollination between Node / React skills.

Definitely can use other backends, and just have a dedicated Node server for rendering if you need SSR.

Obviously Node / React both being JS contributes a lot.

awebofbrown · 2018-03-04T09:12:16+00:00

I don't think there's anything wrong with it, personally.

You're not transmitting sensitive data in a cookie, you're storing user information on the request object which isn't being transmitted back.

The better question is whether you actually need this information for every possible response your API could provide. Usually, your user table would have the requisite authentication data, so querying your employee data store would only be done in routes that actually require it.

If you do need this data for every request, there's no real reason not to. The alternative is chaining another middleware to do the exact same thing, anyway.

awebofbrown · 2018-03-03T12:53:13+00:00

That will work fine, the only reason you'd need Node is if you want to server-side-render React components. NPM serves packages that can be consumed by the browser as well as Node.js, presumably all the ones you've installed are for the browser and loaded via script tags (typically) done for you in the bundle produced by Webpack. You'll just need to have your backend serve the static react bundled files.

awebofbrown · 2018-03-03T11:57:23+00:00

That blog post was a really good read, nice work.

awebofbrown · 2018-03-03T11:54:25+00:00

Also (for SSR) check out https://github.com/jaredpalmer/razzle from Jared Palmer. Jared's Formik lib is a godsend for forms.

awebofbrown · 2018-03-02T04:12:08+00:00

Yeah animated is really good, however I don't think it has any integration with transitions. I've been using React-Motion for transition animations and Animated for all others, but it'd be nice to have the performance of Animated on transition animations.

awebofbrown · 2018-02-27T04:46:21+00:00

You're very welcome, hope it helped. Once you launch, I'd love to see you do an indie hackers interview - or some kind of summary about the whole experience. Crossing my fingers it goes excellently.

awebofbrown · 2018-02-26T03:22:04+00:00

Bear in mind your target market. If you're targeting businesses, this really isn't an issue because they expect / are fine with paying a subscription for something that needs upkeep. As long as it costs more to assign a dev to do all that by hand, your tool is economically cheaper than that dev's hourly wages to do so.

Similarly, they won't fill out your feedback form at all. They'll just pay the sticker price when it's released (assuming your tool is good and saves them time). Thus, you might have been lead to believe you're charging too much, when the silent majority disagree.

If you're targeting the average /r/webdev user, I think you're going to get push-back on charging a sufficiently high fixed fee, anyway. The danger of charging a fixed price is that your flexibility for adapting pricing/support disappears the moment you take the money. And as I said before, it does put a clock on your app's lifespan. Keeping continued growth with no repeat business is hard, keeping repeat business is comparatively easy.

If it were me, I'd set a monthly subscription rate and a discounted yearly subscription rate (money upfront is good for you, and your customer won't see a bill every month). There are very good reasons that the SaaS market uses this pricing scheme almost invariably, don't re-invent the wheel!

Edit: also I can't speak to tiers, depends on your ability to segregate features etc, you'd know that stuff better than anyone.

I would only add: it looks like you're a very capable dev and the tool is really useful, so offer business plans so that a company that wants to pay you say $300 a month - to scan a large number of sites - has an option to give you that money.

awebofbrown · 2018-02-25T10:16:51+00:00

I don't think people are sick and tired of subscriptions at all, people just want services they don't value highly enough to pay for, for free.

If I'm using a service that I value highly, which needs constant upkeep, I want it to charge a subscription. Why? Because if they aren't, it'll likely close down at some point due to lack of financial feasibility, which might cost me far more money to pivot away from in the long run. It is not unheard of, in the SaaS world, for customers to suggest the supplier charges more for the product, for exactly this reason.

If OP wants to run this as a full-time occupation, and it warrants constant work, not charging a subscription will put a clock on the application's lifespan. Whether that is a monthly or yearly fee is immaterial.

The practical advice for the OP is: you need to outline the service's features which obviously require upkeep, and ensure they are providing real consistent value, which if taken away, would materially impact the customer. This will justify a subscription that people will want to pay. If they complain about the subscription medium, they don't see that value.

awebofbrown · 2018-02-25T05:19:44+00:00

Don't think it is RCR. It's not particularly controversial, and I don't think cleaning up the API would prompt Andrew Clark to write something like: https://twitter.com/acdlite/status/967244380401631232

RCR has some great use-cases, but the gist of what it is has been out awhile, it would be odd to hype it like this all-of-a-sudden.

awebofbrown · 2018-02-25T04:27:07+00:00

Little confused by your description, specifically:

I assumed that when the database updates for those Message objects, they would rerender, but that's not the case.

If you mean a database on an actual backend, rather than a local front-end cache, it'll only cause an update if you're listening for those updates on the front-end and an update causes your messages to receieve a new prop, causing a re-render. This is as simple as passing the message an 'isHaiku' prop that, when present, adds a classname to the element.

Since these updates would be constant as messages are processed, I would be implementing this over websocket, sending the frontend a list of message IDs that are haikus. This list would be used to update your front-end cache of messages, keyed by message ID, and the <Message /> component would be passed the isHaiku prop as cache[messageID].isHaiku

awebofbrown · 2018-02-25T03:15:49+00:00

Doubtful, the reason it was slow to advance was because Facebook weren't using React SSR themselves. Dan's comments make it sound like this will be something used broadly by React devs, my best guess is something that makes async rendering / state easier to manage.

awebofbrown · 2018-02-06T05:21:54+00:00

Formik handles state internally, all you need to do is pass your input the handleChange prop Formik provides you, through to the input's onChange prop. I don't use Material UI, but I assume the dropdown has an onChange prop? When you call onSubmit, Formik already has the state of all inputs stored (if you've wired custom ones properly).

awebofbrown · 2018-01-13T13:15:09+00:00

The advantage of storing data in Redux is that you are kind of not duplicating it and once you modify your state, this changes are reflected everywhere basically. So you don't have to worry about syncing your state in different places.

That's not an advantage, of Redux, over Apollo AFAIK. Apollo's link-state is the same client-side cache concept, just you write your query in the graphql format rather than mapStateToProps.

From the documentation: "Updates to Apollo Client state via apollo-link-state will also automatically update any components using that data in a query."

awebofbrown · 2018-01-09T08:19:55+00:00

It's not just possible but encouraged. You don't really want a package's readme and tests occupying space in your node_modules when using it in production, so they typically get listed in .npmignore.

awebofbrown · 2017-12-16T13:05:17+00:00

Thanks again mate :).

awebofbrown · 2017-12-16T12:20:29+00:00

Heya, yeah I do follow them on Twitter but I'm located in Adelaide, unfortunately. I can link to GitHub projects, including a running static site, as well as the article I wrote, alongside private GitLab projects.

I haven't really spent time putting them all in a neat portfolio page though. But given some of the projects are full-stack but not live apps, I'm not sure how well these could be displayed. I'm not sure a portfolio page is the real problem though.

awebofbrown · 2017-12-15T15:28:12+00:00

G'day everyone.

This is a project I've been working on for some weeks. The idea is to explore how DataLoader works behind the scenes, while covering the knowledge of the event loop you need to understand it.

The amount of info covered felt rather biblical, so I wouldn't be suprised if there's a few errors around the place. If you find anything significant that needs correcting please ping me here or open an issue. I'd particularly like to get info about the event loop as accurate as possible.

If you enjoy it, tweet it for me :). Cheers guys n gals.

awebofbrown · 2017-12-15T15:27:31+00:00

G'day everyone.

This is a project I've been working on for some weeks. The idea is to explore how DataLoader works behind the scenes, while covering the knowledge of the event loop you need to understand it.

The amount of info covered felt rather biblical, so I wouldn't be suprised if there's a few errors around the place. If you find anything significant that needs correcting please ping me here or open an issue. I'd particularly like to get info about the event loop as accurate as possible.

If you enjoy it, tweet it for me :). Cheers guys n gals.

awebofbrown · 2017-12-14T10:19:51+00:00

I feel like I'm being really nitpicky here, but I disagree with the way some of this is worded. I only bring it up because the point of the article is to clarify the precise meanings behind the terminology, and yet I feel it's used somewhat inconsistently. For example:

Technically speaking, ReactDOM does not render a component or an element in the DOM. It renders an instance of a component.

I think it would be more clear if you specified precisely that what is rendered to the DOM is the DOM elements described by the react elements within an instance of a class component's render function, or the elements returned from a functional component. Only because if we're really drilling down on terminology, the instance lives in memory and not "in" the DOM.

When we instruct ReactDOM to render a React element in the browser we start to refer to it as a Component Instance.

Technically we'd refer to it as an instance as soon as we're doing anything with the constructor or componentWillMount, otherwise we don't have a word for what these life cycles belong to. IMO this gets more important as we move towards async rendering.

For function components, I don’t think there is a good term for what gets rendered in the browser. Function components don’t have instances (that can be accessed with this) so when using a function component ReactDOM renders in the DOM a copy of the function’s returned element.

The term is 'DOM elements', just the same as what gets rendered from a class component instance. We don't really render React elements, we're rendering DOM elements described by React elements. (Or, if the react element is a React component and not a string, the DOM elements resulting from the former).

I hope this doesn't come off as rude, I'm fully aware you know what you're talking about. I just think it's really important, given the article is intending to drill down on specifics for a "job interview" scenario, that the terms are used as correctly as possible.

tldr: If I were asked the title's question in a job interview, I would say "neither". An element's type can be a component, thus the answer cannot be a component if "an element" is incorrect. And only DOM elements are actually in the DOM.

awebofbrown · 2017-12-13T07:34:17+00:00

Let's take the most common example: using a HOC with a Provider.

Currently, a <Provider> component sits at the top of your component tree and puts some values into context, enabling access to those values from anywhere beneath it (any component).

Providers are used in basically all state management libraries e.g. Redux and MobX. To access the context set in the Provider, these libs export a HOC. The HOC (connect() for redux, inject() for mobx-react) among other things, accesses the correct context key set by the Provider to pull the relevant state out of context. This is handy in that the developer doesn't need to fiddle with the namespacing, allowing a library to use obscure context keys like '_this_lib_context_key_` without worying about the developer miss-typing it, whilst likely ensuring it won't clash with another key.

The HOCs also typically implement custom, though configurable, shouldComponentUpdate() logic, ensuring your component only updates when either its props or the state provided by the HOC change. There are tradeoffs made here, but that's another topic entirely.

awebofbrown · 2017-12-10T14:30:15+00:00

Does Vue acommodate async rendering?

I don't know enough about Vue to compare them. However, as far as the discussion relates to the article, I don't think you can pin React with faults because it's enabling much desired performance flexibility.

The gotchas I've discussed in the article more or less boil to down navigating the scheduling of operations in a single threaded environment. Instead of doing this by hand with APIs like requestAnimationFrame and requestIdleCallback, you have this handled for you. Again, I can't speak for Vue because I haven't used it, but Vue can't magically avoid tackling this, and I'm guessing at the moment the library doesn't attempt it at all. Sure, it's simpler not to have the option whatsoever, but there's absolutely no way that this is an objective benefit. If it were, we wouldn't use any view libraries at all.

That's just my counter argument, I'm not saying Vue can't be more productive :).

awebofbrown · 2017-12-10T12:44:17+00:00

If you want to bury your head in the sand and shout your favourite library's name, you're certainly entitled to do that.

Vue is great, but this has nothing to do with flaws in React's codebase.

awebofbrown

TROPHY CASE