Make render-function curried about preact HOT 5 CLOSED

It's not something we're going to add for size reasons and because it's too much of a niche use case. You can always add a custom wrapper around render in your project.

import { render } from "preact";

const curriedRender = domNode => vnode => render(vnode, domNode)

from preact.

my bad after all, I checked the source and problem was that render has 3 arguments. Not this.
so it can be curried like so.

export const cRender = curry(binary(render))

from preact.

I'm not sure it makes sense to make changes in an extremely size-conscious lib to support an authoring style that is very niche/far from standard.

Additionally, in the context of a Preact app, I question what value that is even providing? Typically, these patterns are used in FP languages for a (subjectively) better authoring experience when it comes to handling errors. However, if the mount point of your Preact app doesn't exist, in all likelihood it should error out and die, there's not much you can (safely) do at that point. Non-null assertions make much more sense here.

from preact.

I wouldn't say functional programming is niche 🤷 - React went from classes to functions and so did Preact.
Error handling in FP is a matter of adding it to my example, which I omitted as it is not relevant to this ticket.

This isn't about authoring style, this is a about best practices where the usage of "this" is generally considered bad. Currently the render function cannot be curried, because of it.

Non-null assertions are code-smell.

from preact.

I wouldn't say functional programming is niche

The concept isn't, no, but adding utilities to facilitate it (Maybe, ifJust) and trying to curry render() certainly is.

Preact has a fair number of users and this is the first I've seen of someone trying to author like this. Same goes for React, though I'm not reading as many of their bug reports/examples.

this is a about best practices where the usage of "this" is generally considered bad

This really isn't the case. Like many things, it's a tool to be used at certain times and places.

Non-null assertions are code-smell.

That's your opinion, but you can use a // @ts-ignore in its place I suppose? In Preact apps, where you control the render container, non-null assertions make perfect sense as you can guarantee it exists. If it doesn't, that's an issue for you to fix, render() should error out in that case.

Unless you can suggest a 0-byte cost change I don't think this feature is likely to land. It's not that currying is inherently bad or anything, but for a size-conscious lib, it doesn't make a ton of sense to increase in size to support a really niche alternative authoring form.

React went from classes to functions and so did Preact.

This isn't relevant to the issue, but unlike React, Preact is not "moving to" functions really. They're an option you can use, but classes are still supported as first-class citizens and will continue to be for the foreseeable future.

from preact.