Building React Apps With Nova

Nova is what I’m calling the new React-based version of Telescope. One of my goals for this version is to make it possible to not only use the normal Telescope features like posts and comments, but also easily add new collections for any kind of data.

Here’s a short video showing how that works:

http://www.telescopeapp.org/blog/building-apps-with-nova-react-meteor/

The features we’ll build include:

  • Publications
  • Subscriptions
  • Pagination
  • Joins
  • Methods
  • Forms

And all that generated automatically for you from your collection schema, with barely any back-end code!

At this stage this is mostly a proof-of-concept, so I would love to know what people think of this approach. Also, I’ve extracted most of Nova’s features into their own separate packages, which you can already use right now in your own app if you’d like.

13 Likes

Took a close look at Nova Forms today. Amazing work! All the good parts of Autoforms without the abstraction layers causing all the headaches!

So, alternative GUI libraries… specifically, Material UI. I know this opens a pandora box… support lots of libraries with convoluted if/then statements, kludge things with a plugin architecture, or encourage forks of the package. Any opinion which direction you’d like to go for people who want to use Nova Forms, but with Material UI?

1 Like

A plugin architecture (nova:forms, and then nova:forms-bootstrap, nova:forms-material, etc.) seems like the best option, but I’ve been thinking about the upcoming move to NPM and I don’t know how that would work in that context.

The plugin type architectures I’ve built with Meteor’s own package system tend to rely a lot on globals and circular dependencies (i.e. if (typeof NovaForms.bootstrap !== "undefined") { ... }) but that’s probably not a good idea anymore…

So right now my best idea would probably be doing something like this:

import NovaForm from "meteor/nova:forms";
import BootstrapComponent from "meteor/nova:forms-bootstrap";

...

<NovaForm component={BootstrapComponent} collection=...>
1 Like

Awesome work! But I do wish there was the option to use a schema instead of collection(with attached schema) in a form.
Did I miss something in the docs or is this highly intentional? aldeed:autoform supported schema= in addition to collection=, which is sometimes quite useful.
For example for complex filters and such.

If you get this feature in, I’m likely switching from my current setup :slight_smile:

I just published a version that accepts schemas as well: https://github.com/TelescopeJS/Telescope/tree/devel/packages/nova-forms

Again I haven’t really tested the package outside of Nova though, so I don’t know if it’ll work out of the box right away.

2 Likes

With the current 1.3.2.4 “bug” where source files are really slow to scan (especially down the node_modules rabbithole) I’ll wait until it’s published. I suspect manually putting it in packages might work poorly for the package caching? Or?

Already have reload times of ~10s. With chimp(which followed MeteorChef Base) I had almost a minute due to the huge size of node_modules

But as soon as it’s published I’ll try it out! :slight_smile:

Gave it a go.

Was even unable to use nova:forms stable as it depended on the Telescope namespace.
nova:core was installed, but perhaps the load-order messed it up?

Oh right I forgot it depends on Telescope for the flash messages. That’s a
really small thing, I’ll remove that dependency tomorrow.

I rather like that syntax. If the props pass through the components and provide a common interface, that would be perfect. My guess is that there will be some differences, however, and nova:forms-bootstrap, nova:forms-material etc will need to take care of mapping inputs/props from NovaForm to the various framework specific inputs. But otherwise, looks like a great approach. Lots of learned lessons here. :wink:

Love this! Something I asked you on a random hangouts chat a while back “Will you consider making Telescope a generic container management system”.

Am going to try it out and see how we could implement a resource listing service / classifieds etc. All of these are generic extensions of the posts collection with custom fields and custom behaviour - something similar to what we’ve done in a very hacky / awful way on GeoExpat.Com in PHP.

Hi Sascha ( @sacha )

impressive work and really good documented source code. Let me ask what you think about the “mantra style”. As far as I can see this is not the mantra of nova?

Would you call nova to be more a “boilerplate” or is it already a kind of “framework” for new projects?

How would you state nova to the “orion” and “astronomy” modules.

Thanks for some explanation, it is hard these days to decide on what “stack” to start when beginning new projects. Every day something new is around :wink:

TomFreudenberg

Thanks! Mantra is great, but we didn’t adopt it for a couple reasons. It felt a bit too complicated, and it didn’t really support SSR when I looked at it. But we’re moving towards more of a Mantra-like architecture anyway, so we’re using similar concepts even if we’re not using the actual Mantra.

And Nova is more like a framework than a boilerplate. I’m not super-familiar with Orion, but it would sit on top of Astronomy (although it uses SimpleSchema). You can basically think of Nova as a back-end + UI layer on top of Meteor.

Thanks @sacha - your answers meet my expectations. I will definitly check your “app layout” - especially your technique/api for hooks and extensions are looking neat.

Cheers
Tom