In this mix I'd swap in Rekit (http://rekit.js.org/) instead of plain create-react-app as it adds Redux with lots of timesaving functionality built into an included editor.
The newest version is built on top of create-react-app so yes you can eject, I haven't done so though. You can use whatever editor you like, but you won't get the automated features like "Create Component" setting up your js, css, tests, and routes automatically. I expect this will be the biggest stumbling block for most devs. I may be unusual that the transition from sublime to the web based editor was very smooth and didn't slow me down.
I love how ant design invents a new 'design language' and then it turns out to be yet another bootstrap.
I wish we'd get a real revolutionary design system instead of these frameworks that try solve all cases, and ultimately end up so generic you can't use them for anything -other- than prototyping
What I would love to see in a design system is something in terms of "white-label" components. I'm talking about components with great UX, but basically no styling applied.
I'm not sure if what I'm talking about is possible, and I'm not sure what it would look like -- but I'd love a framework that just makes everything work really nice - except it doesn't force you to do really quirky css hacks to re-style the thing.
Agreed. I'm surprised not to have seen this. It reminds me of the "skeleton" wordpress themes from ~10 years ago. You get a view layer that's marked up and connected/connectable, but that has no styles.
Can't you change the style of a Bootstrap layout without changing the functionality? I thought that is the point of all the different "themes" they have.
Initial look at the Ant Design, all of the images in the documentation are broken, so is the ng.ant.design URL. That's not inspiring any confidence in their ability guiding web application development...
"Firebase’s core product is a real-time database service. This means that your users do not need to refresh a page to see updates to the state of the application and it"
"Once you have your Firebase project, provision a “Cloud Firestore” database"
Cloud Firestore is a traditional NoSQL DB and is not the realtime database product.
“Cloud Firestore is a flexible, scalable database for mobile, web, and server development from Firebase and Google Cloud Platform. Like Firebase Realtime Database, it keeps your data in sync across client apps through realtime listeners and offers offline support for mobile and web so you can build responsive apps that work regardless of network latency or Internet connectivity”
from the ant front page: "A design system with values of Nature and Determinacy for better user experience of enterprise applications"
This looks like someone spent a ton of time building something that is probably very useful. So, with all due respect, what the fuck does that even mean?
In all seriousness, this is the crap that many company types buy. What they won't be is an easy and straightforward explanation of what it actually is. You want extra points in a meeting? Just tell them you're integrating that quote for increased utilization of all structured experience parameters. 99.4% utilization. And you think next quarter you can get that up to 99.6% — and of course, something about how it's free. They already know they don't fully understand, and they don't want to be reminded. what they want is to feel they're speaking the same language. It's crap, but its necessary in industries that aren't necessarily that involved in the tech or design.
This is alibaba's react component framework. It's extremely high quality, but unfortunately most the english is translated from Chinese, so awkward grammar is abound. I suggest looking past that.
I think the tutorial would be more complete if the example showed some basic security rules. Even if it's a prototype, there is the chance that a joker will delete all your test data live during a demo.
I still can't believe everyone has accepted mixing logic and presentation is a good idea. Html mixed with javascript is a mess and I can only imagine what a "mature" React app looks like after a few years of iteration. I can't wait for the "React turns out to be a shit idea" posts in a year or two just like we're seeing with microservices. It's like a mass hallucination or something. Maybe Facebook had Cambridge Analytica help them market React or something. At least that would explain the brainwashing.
This is such a poorly done react app, you can not take this as the current state of react. If you've never seen a mature react app, and have at best checked out a few blogs that try to compare it to other frameworks, then you have not been exposed to nearly enough to make a real decision and are throwing around empty opinions.
I'll admit mostly ignorance since I've only done a Udemy react course and read some blogs. However, I've never seen it done any other way. Isn't JSX an integral part of React?
I wrote an extended answer to this on Reddit a few weeks ago [0]. I'll paste it here for ease of reading:
JSX is not required. Literally, all you need is to include script tags for `react.js` and `react-dom.js`, and then you write "raw" `React.createElement()` calls.
However, most people find that to be too repetitive. So, the "default" approach is to use JSX syntax, which converts `<MyComponent a={1} b="blah">Text</MyComponent>` into `React.createElement(MyComponent, {a : 1, b : "blah"}, "Text")`.
Yes, JSX requires a transformation/compiler step. As I said earlier, a typical "real" app needs build tools to bundle anyway, and you're probably targeting a variety of browsers but don't want to restrict yourself to the least common denominator subset of JS syntax, so you're probably already using a transpiler too.
But, if you truly don't want to use JSX for whatever reason, there's plenty of choices:
- Write raw `React.createElement()` calls by hand
- Alias `React.createElement()` as `h()` so it's shorter
Almost everyone chooses to use JSX. The docs use JSX. Tutorials across the internet use JSX. It's the accepted approach. But, it's not _required_. You do not _need_ it. There are other options. It's your choice.
I'm not a huge fan of react either. To be honest, I don't know it very well, but we tried using it for an MVP, and things just took way too long. Ended up redoing the entire MVP as a rails project, which I didn't know either, but was able to make a fast MVP with.
You can keep a very comfortable degree of separation between logic and presentation with React, and there are multiple ways to do so, such as using Container Components for state-management and stateless Presentational Components for the actual appearance of your app, using Higher-Order Components, or the "Render Prop" technique that's been making rounds lately . I am working on a React SPA and I have no problem at all keeping things such as data fetching, local state and what not separate from the presentation, either in my codebase or in my head.
Logic and presentation are not mixed. The logic is inside the Class methods and the presentation is inside the Class render(). You can also move the logic outside of the Class component (that's one reason to use Redux).
And you can also create stateless components without any logic, eg.:
I thought the same. But, as I started to work with react in a side project, now I really enjoy it. In the beginning is a really mess. But, as you begin to think in a "data stream oriented way" (like you do in Haskell with lists), your templates look like any regular framework. It stay isolated in a function with no more than value substitutions. You even can separate in a different file. The only really JS code I have mixed with html has "if" and "map/for" statements. This is, yet, the uglier part for me (at least, now).
BTW: I don't use redux (and I never will!).
Plus, isVisible in React is not a string but a variable, so you can use Rename Symbol and Find All References on it, inspect its value in your browser's debugger, inspect its type if you are using TS or Flow, and so on.
47 comments
[ 3.2 ms ] story [ 94.0 ms ] threadThis adds Ant so I'll have to check that out. Thanks!
I wish we'd get a real revolutionary design system instead of these frameworks that try solve all cases, and ultimately end up so generic you can't use them for anything -other- than prototyping
Side note, this is what I'm looking to solve at https://cleverbeagle.com.
I'm not sure if what I'm talking about is possible, and I'm not sure what it would look like -- but I'd love a framework that just makes everything work really nice - except it doesn't force you to do really quirky css hacks to re-style the thing.
If that makes any sense :)
I'm glad that there's a good UI lib that integrates with React at this level.
"Once you have your Firebase project, provision a “Cloud Firestore” database"
Cloud Firestore is a traditional NoSQL DB and is not the realtime database product.
https://firebase.google.com/docs/firestore/
https://firebase.google.com/docs/database/rtdb-vs-firestore
This looks like someone spent a ton of time building something that is probably very useful. So, with all due respect, what the fuck does that even mean?
In all seriousness, this is the crap that many company types buy. What they won't be is an easy and straightforward explanation of what it actually is. You want extra points in a meeting? Just tell them you're integrating that quote for increased utilization of all structured experience parameters. 99.4% utilization. And you think next quarter you can get that up to 99.6% — and of course, something about how it's free. They already know they don't fully understand, and they don't want to be reminded. what they want is to feel they're speaking the same language. It's crap, but its necessary in industries that aren't necessarily that involved in the tech or design.
JSX is not required. Literally, all you need is to include script tags for `react.js` and `react-dom.js`, and then you write "raw" `React.createElement()` calls.
However, most people find that to be too repetitive. So, the "default" approach is to use JSX syntax, which converts `<MyComponent a={1} b="blah">Text</MyComponent>` into `React.createElement(MyComponent, {a : 1, b : "blah"}, "Text")`.
Yes, JSX requires a transformation/compiler step. As I said earlier, a typical "real" app needs build tools to bundle anyway, and you're probably targeting a variety of browsers but don't want to restrict yourself to the least common denominator subset of JS syntax, so you're probably already using a transpiler too.
But, if you truly don't want to use JSX for whatever reason, there's plenty of choices:
- Write raw `React.createElement()` calls by hand
- Alias `React.createElement()` as `h()` so it's shorter
- Use a functional VDOM wrapper generation library like `react-hyperscript-helpers` (https://github.com/Jador/react-hyperscript-helpers/).
- Use a runtime JS templating library like Dominic Gannaway's `t7` templates(https://github.com/trueadm/t7)
- Use an actual separate templating library, like `react-templates`(https://github.com/wix/react-templates) or `handlebars-react`(https://github.com/stevenvachon/handlebars-react)
Almost everyone chooses to use JSX. The docs use JSX. Tutorials across the internet use JSX. It's the accepted approach. But, it's not _required_. You do not _need_ it. There are other options. It's your choice.
[0] https://www.reddit.com/r/javascript/comments/81fkhi/this_may...
And you can also create stateless components without any logic, eg.:
The Firestore API seemed quite similar to MongoDB which I haven’t used in a number of years. I might give that another try as well.