jador / react-hyperscript-helpers Goto Github PK

Hi,

what's the idea behind the "isRendered" property?

Wouldn't it be more straight forward to do this

shouldDisplay &&
h(Khaled)
// -> null

instead of this

h(Khaled, { display: false });
// -> null

?

Am i missing something or is this just personal preference?

Hello,
I tried your library, which is great so far to replace JSX.
I have an issue with the "key" property, as soon as I pass more than one component in the array of children, I have the warning that I need to add a "key" prop to each children.
I'm pretty sure it's not needed with JSX when you declare components without explicitly passing an array :

// key prop is added automatically I suppose ?
return (
  <div>
    <Component1 />
    <Component2 />
  </div>
)

So my question is, is it possible to add this key prop automatically ?

Personally I am a big fan of css modules. The composition of selectors is just lovely.

However, if you use composition you can't just drop the result into the selector param.

Example:

.alpha {
  margin: 0 auto;
}

.omega {
  composes: alpha;
  padding: 1em;
}

import React from 'react';
import { hh, div } from 'react-hyperscript-helpers';

import classes from '../styles/some.css';

export default hh(() => div(`.${classes.omega}`, '\u03A9'));

The omega class will actually be two classes (some_hash_a some_hash_b) and so by dropping it into the selector param only the first class is picked up. The second one will be ignored because it is not a proper selector.

Of course there are ways to work around this. One could simply use the className prop as you would with JSX or do a string replace.

We could bring this concern into the library.

One way would be to produce a utility to provide a proper selector.

Another option would be to treat space delimited portions of the selector param as a class.

Or we could not be concerned about it at all.

Any thoughts?

I'm not clear what the benefits of this package are over just combining hyperscript + hyperscript-helpers.

The readme asserts that it:

Allows for expressing UIs in the hyperscript-helpers style but with first class support for React.

The api has been greatly improved, making the library usable for actual projects.

Having successfully used the above pairing for actual projects, I'm not clear on what the differences are between this package and libraries that inspired it 🙂

It wouldn't hurt to add better documentation of the api.

Quite a number of tags are not supported by the library that React does.

This should be remedied.

React Router does not like factoried components for the component prop of a route

I've discovered this young library: https://github.com/sultan99/react-on-lambda. I think it is worth mentioning in alternatives. Although I am not sure whether its API is compatible with hyperscript.

• rewrite in typescript
• modernize toolchain
• provide transpiled and raw source in package

Simple question : how to add event handlers through the hyperscript helpers. I naively tried :

h(Counter, { count, onClick: trigger(BUTTON_CLICKED) }, [])

but that failed lamentably

Previously, you were not required to use an array if you had a single child that was a string. Due to a convenient mistake on my part you could also do this with a component.

As of the changes I made yesterday (#4), this now works for numbers as well. However, you are now required to use an array when you have a single component as a child.

I know different hyperscripters have different opinions on whether or not children should always be an array. I want to get a pulse on how those using this lib feel on the issue before making a change.

Personally, I kind of like how this has shaken out. It seems like if you only have a single primitive child that the component is pretty simple and it might be nice to just say 'bob' and be done with it. Whereas, if you have a single component being forced to use the brackets could result in cleaner code.

Thoughts?

What about adding eslint to project and a new npm script to lint it before generating a new build?

Hi.

We are using Typescript 2.0.3 (the latest) in a project. You ship with the NPM pkg an index.d.ts which apparently doesn't work with my version. Here are some examples of the many errors (all related to a missing argument to a type with a generic):

node_modules/react-hyperscript-helpers/lib/index.d.ts(528,44): error TS2314: Generic type 'ReactElement<P>' requires 1 type argument(s).
node_modules/react-hyperscript-helpers/lib/index.d.ts(529,62): error TS2314: Generic type 'ReactElement<P>' requires 1 type argument(s).
node_modules/react-hyperscript-helpers/lib/index.d.ts(530,52): error TS2314: Generic type 'HTMLAttributes<T>' requires 1 type argument(s).
node_modules/react-hyperscript-helpers/lib/index.d.ts(530,90): error TS2314: Generic type 'ReactElement<P>' requires 1 type argument(s).
node_modules/react-hyperscript-helpers/lib/index.d.ts(531,34): error TS2314: Generic type 'HTMLAttributes<T>' requires 1 type argument(s).
node_modules/react-hyperscript-helpers/lib/index.d.ts(531,72): error TS2314: Generic type 'ReactElement<P>' requires 1 type argument(s).
node_modules/react-hyperscript-helpers/lib/index.d.ts(532,44): error TS2314: Generic type 'ReactElement<P>' requires 1 type argument(s).
node_modules/react-hyperscript-helpers/lib/index.d.ts(533,62): error TS2314: Generic type 'ReactElement<P>' requires 1 type argument(s).
node_modules/react-hyperscript-helpers/lib/index.d.ts(534,52): error TS2314: Generic type 'HTMLAttributes<T>' requires 1 type argument(s).

I think the correct approach would be to remove the types from the default NPM pkg, release them under @types/ so that custom declarations can be included or if someone uses and older version or newer of the types they can handle a out of the situation and include the applicable typings.

I have been unable to find a way to not read the included declaration so my project simply breaks because I cannot edit a node_modules file to fix the types.

I opened a related question in StackOverflow and I'm simply stuck and I think I'll have to vendor the code manually and avoid NPM. :(

I'm not entirely convinced about the correct way to treat this, any help is appreciated and if applicable maybe this should impact the next release?

Thanks!

It might be cool to add that so people can find the GitHub repo through npm easier.