Can somebody that's like super smart on React tell me what would be needed to implement this thing in React? The current stuff is Angular, and its code can be found here. What I would need is as follows.
- A suggestion to which components and plugins (middle of the road stuff, the stuff that "everybody" is using)?
- A suggestion to which CSS framework (or whatever) to use?
The way it's generated is as follows. If you want to reproduce the generate process you can sign up for a cloudlet here.
Alternatively, if somebody wants to actually do this, feel free to hook me up at th@aista.com if you'd like to get paid doing it for us ...
At moderators; I've had the tag "discuss" removed from 3 of my posts. What is its purpose? I would assume something like this would be OK, or ...?
Top comments (16)
Hi Thomas,
The discuss tag is for discussions and most of the other posts are opinion posts. On the other hand, you can add the tag #help on this post and maybe #javaScript and #programming 😁
I think it would be quite straightforward, if you already did it with Angular, copying the same on React wouldn't be that difficult.
Now you're using material and hence mat-form-fields. You can use standard inputs for the data with React in the CRUD process. On the styling thingy you can stick with material if you like it, or go for a self implementation through styled-components if you prefer something built for the specific target and give a nice feedback quickly based on user actions through JS events/state.
I'd use lazy loading for those components (the ones that appear when you choose any left bar category) like it is in this Angular implementation as there are many "categories".
On the rest, the implementation details can vary depending on the needs. The key could well be in this sorting/searching/filtering; i.e. Do you need throttle or debounce in those calls?
I assume that it's generated using templates so the same way you worked with angular templates and components, you can split React components and build different templates containing N components each and sending the required data to any of them.
My question on that is, if you've a working angular implementation why do you want to re-implement it on React?
Thx, great advice. We're doing debounce to avoid HTTP request "storm". Reasons for reimplementing is that some of our customers needs React output, and are turned off by Angular. So my opinion here really becomes irrelevant ... 😕
I'll add help tag ASAP 😊
As to why React? The output is just a "starter kit" to apply customisations to after the "generator" has done its thing. Think "ng generate" on steroids ...
Reasonable.
I'll throw a triple and tell me if it's right 😂
Is it that or does it also uses dynamic routing with multiple endpoints?
I would love to give you a tour. Fundamentally it is only ONE endpoint, dynamically resolving Hyperlambda files. It is basically "FoxPro for the web". Ridiculously simple to use + meta programming capabilities 😊
But this server can output (and maybe receive) different data models and the need is to dynamically build CRUD forms and views with filters using those N fields, isn't it?
Yup. These are the parts we've automated. There's nothing preventing you from doing other things in it. It is Turing complete ...
Can you share a couple of examples of those server responses to see how the CRUD could be built with them?
I already did that kind of jobs in different projects and for different targets
I can do better in fact. Check out our sakila app, login with admin/admin, and click F12 - Then do some paging and filtering in for instance the "actor" table. This is a 100% automagically "generated app", and it didn't have a single line of code manually added to it.
Then realise that we also built our entire middleware in Hyperlambda, however not automagically, but by manually writing most of the code ourselves. You can check out the result here.
Let me check it in more detail in a couple of hours, I'm reaching you through LinkedIn if it's fine.
Go bro!
Hey Thomas,
I think Joel's answer to your questions about #discuss is great but wanted to elaborate just a wee bit...
Recently, I've been stricter on removing the #discuss tag from posts that aren't specifically geared toward starting a discussion and following our submissions guidelines for the tag:
Now, I'd definitely understand if you were to miss these guidelines as they're tucked away on the #discuss tag landing page. I think we should likely put these guidelines directly in the editor somewhere.
Also, I understand wanting to use the tag #discuss because you want people to comment. However, we're trying to treat the tag as something more specific, so that folks can expect a specific type of post when reading #discuss.
The reason we're doing this is because we want folks to easily be able to find posts that are for discussing certain topics as opposed to more editorialized posts. We really want #discuss posts to take on the form of a prompt that folks can then discuss down in the comments. And, we encourage authors to drop their own response in the comments if they wanna elaborate on the discussion topic, because this way the discussion prompt gets the primary focus and folks can then discuss things down below on an equal level (author of the prompt included).
To be honest, I should probably write an article about all this because we've been removing this tag from lots of folks' posts recently. But yeah, it's all about organizing the site and making it so that folks can more easily discover what they're looking for. So, when folks follow #discuss, they know that they'll get posts with discussion prompts.
Thx Mike, makes perfect sense 😊
No probs at all! It's a good question. Really appreciate ya being so understanding! 😀
I luv this place, so no worries from me ^_^
Maybe you can use Nextjs instead react. More precisely: nextjs over react. next.js is higher order framework of react. You can build FE and BE in single app.
Thank you for the advice, but I'm really just interested in the frontend parts.