Frontend templates built for redwood?

TailwindUI.com and Flowbite.com are both excellent UI Component libraries using Tailwindcss.

3 Likes

Thanks, all. I’m going to give Chakra a try.
Also, just came across this collection of links, which might be useful to anyone getting started w Chakra:
https://github.com/chakra-ui/awesome-chakra-ui

Specifically:
https://chakra-templates.dev

1 Like

This discussion is more than a year old - given the speed of “Frontend Templates” growth. none of the references shared here are likely to be relevant today. The issue itself, however, is more relevant than ever before.

@mattsears18, @thedavid @pete - you wrote a few remarks in this post, which give indications of where to look for solutions, but nobody wrote anything about how to use them in the context of a RedwoodJS app.

While I started a discussion with the title How to use RedwoodJS applications with several UI component libraries, I did not intend to write all of its planned contents (I did write a good sized example showing Chakra, though, with the following comment

This whole article is written because I need to choose a UI toolkit for my future app development projects While doing this research (based on suggestions in RW online documentation I decided to keep detailed notes so, someone else can benefit from my work. There is no expectation of getting other people’s comments - but do not let this remark discourage you from asking questions.

Perhaps @thedavid can provide his opinion about the intent of https://community.redwoodjs.com discussions. Is it meaningful to expect the community members to provide a more detailed information about something they already solved, for the benefit of others?

As a great example of moving towards the goal of having RedwoodJS integrated with Chakra, please check Chakra UI with ‘redwoodjs/forms’ elements which explains a lot deeper integration than my very basic example at How to use RedwoodJS applications with several UI component libraries.

Thank you @mattsears18, @thedavid, @pete, for sharing your experiences. Realizing that this effort might signal the common need for more formal creation of RedwoodJS-UI, @thedavid may I ask you to start it?

Realizing that this effort might signal the common need for more formal creation of RedwoodJS-UI, @thedavid may I ask you to start it?

@adriatic do you mean a new Forum Category for UI?

As I’m progressing along my first non-trivial project with RedwoodJS, I start to wonder if the codegen mechanism could be made more generalized and user-configurable.

  • Generalized in the sense that it can be used to generate anything, including popular UI elements. And even better if generators can call each other.
  • User-configurable with templates as well as other relevant specs being under user control.

This has potential to help the ecosystem explode with user contributed generators. For the UI usecase, this could mean the availability of a bunch of different UI libraries with just a call like yarn rw g chakra-gen [chakra-gen params].

After a somewhat painstaking effort to setup JWT authentication, with roles, authentication forms, navbar, user account menu in navbar, about page, privacy policy page, terms and condition page, etc… I wouldn’t mind the ability to easily be able to re-use this for my next app so I can immediately start work on the actual business logic.

Alternatively, we could also consider an architecture that is friendly to integration (plugins?). My only other “real” web experience is with Django in the Python world, and they have a very good reusable app architecture where each app is essentially a feature, and multiple apps together form an application (e.g. auth app + product app + star-rating app). That helps getting the backend (with a somewhat ugly frontend) up and running real quick.

Have you tried yarn rw setup generator? How far does that get you towards your goal? What’s missing?

We are thinking about, and working towards, plugins. Could you please expand on what you envision for plugins? It would help guide us in our implementation discussions :slightly_smiling_face: Thanks!

Maybe build in components for redwoodjs similar to this Jumpstart Docs | Buttons

@adriatic do you mean a new Forum Category for UI?

Yes, as this is the best option we have at the moment to initialize and conduct a basic discussion that could define content to be written as an RFC.

Since this discussion started, I “evolved” a bit and would like to extend the term Frontend templates built for redwood to a more general one RedwoodJS templates see NextJS templates as a very nice commodity for developers.

In order to do this right for our context, we need a good balance between using generators (which “know” where to insert the generated code) and templates that most likely expect to be added manually. Each such template should have its own metadata (telling how to include it in your program) - see this as an example

Hi @Tobbe,
Thanks for responding. setup generator looks pretty awesome and it probably would solve a bunch of issues I encountered during the past weeks. Sorry I missed this part (side effect of piece-meal learning while trying to get a project off the ground). Let me try it out for a few days and will share if I have any constructive thought to add.

Regarding plugins, coming from Django, I do miss the ability to get a non-trivial app up and running my connecting reusable apps. Combine that with the fact that in the Node ecosystem, we can the same js/ts language and share code between server and clients, such a mechanism would be much more powerful.

To enable such capability, I imagine a plugin architecture would need to allow addition and removal of items in any of the major layers of the api, as well has having some kind of middleware concept. Same is true on the client side (components, pages, and hooks).

Since redwood is all about helping startup get off the ground, I can think of a few plugin use cases that would be of immense value to startups:

  • bootstrap landing page + signup/waitlist collection
  • vendor-specific auth with roles (complete with client side forms as well as vendor-specific getCurrentUser)
  • feedback gathering,
  • an admin UI (with scaffolded CRUD methods and user defined custom scripts) that is secured by default.

These are probably tall orders when starting from scratch, but you guys have done such a fantastic job so far and it’s good to be ambitious :slight_smile: I’d be glad to contribute some time when the need arise as well.

1 Like

I believe that @tvo is asking for similar features, as I did above.

@Tobbe I have 3 suggestions regarding generators at this time. But as a preface, this could easily be me not fully understanding the tools available. I’d appreciate it if you let me know that I’m wrong or if there is a readily available alternative that I’m not seeing. That would help me ramp up fast and become a more useful member of the community here! That said …

  1. Would love to have the generator features that are model-related to be able to accept a list of models instead of just 1 (and dare I say even an --all switch`). This would make the initial ideation workflow go a bit smoother, as well as the case where one needs to regenerate code for multiple affected models.

  2. Would love to have access to the generator template for script also. Right now it’s not an allowed option in setup generator.

  3. Also would be fantastic if there is an arg that we can pass to the generator to support RBAC. Even better if this arg could be set in a config file like redwood.toml so code can be scaffolded with @requireAuth([ADMIN]) by default.

I’d be happy to contribute PRs if we have an agreement that these would be useful features.

What if there was “scaffold schema” or “g sdl schema —force” to do all models?

For the requireAuth with roles, you could:

  • make your own validator directive called requireAdmin and implement logic
  • update template to use that directive instead

That way your auth rules are encapsulated in a directive rather than arguments

1 Like

Imo it’d still be useful to control which models via a list. The particular case I’m thinking about is scaffold or sdl regeneration where you don’t want all your models overwritten because you may have custom mods for some models.

This is a great idea! Much cleaner than what I suggested. Thank you!

This sounds like an obvious addition/enhancement of what we currently have. Please create a PR for this :slightly_smiling_face:

Sure. I’ll put something together tentatively by this weekend. This should get my feet wet with the generator subsystem before formulating an approach to the prisma/typeorm issue

We created an internal tool for integrating some of our favourite MUI templates into redwoodjs that we’ve had some success with.

If you’ve ever tried to integrate some of the MUI templates it’s a pain in the ass and takes ages.

check it out here if interested: https://templatesrw.distinct.au/

1 Like