I have to do a POC for a project based on React/Redux. This application will grow later to be big and complex website.
This is important decision to take early than later I guess.
Should I go with Typescript or not. I am so confused as there are so many options these days.
Other module I will used are Material UI , React router , Thunk, Formik etc..
Thanks
Anuj
as most things in coding it's a matter of choice for you and the requirements you have
if you want more strict type checking at compile time then go with Typescript and utilise the power it gives you
but be weary there is a learning curve with it and some errors are not as clear to solve as others and it will add time to development
so it's a balancing act and you need to decide if the benefits it gives you outweigh the cost of the learning and development time
Please go ahead with Typescript.
It is suitable for applications with huge code.
Due to the static types, several IDEs are able to offer even more predictive assistance than usual (with an instance of a class and its attributes, for example).
Types have a proven ability to enhance code quality and understandability.
It is optional to assign types. You can always write a Javascript code in Typescript but the reverse is not possible.
Types make the code more readable. It helps the developer remember faster what each piece of code is supposed to do. Hence, the developer can add and change the current code faster.
Don't worry about libraries. Most libraries have a package for types as well. Eg. #types/material-ui for material-ui
Related
This might seem like a generic question , I really liked the scalability of material ui when compared to couple of other react open source frameworks..
Question Whats the difference between components in "#material-ui/core and "#material-ui/lab?
The material ui documentation says "This lab hosts the incubator components that are not yet ready to move to the core." So when it says the components are not ready to move to core, what does that mean? (Im looking for something a bit more deterministic like the component has not been completely tested/waiting for user reviews/ major bugs can be expected etc etc).
For eg WRT code in the below sandbox ,it uses #material-ui/lab/Autocomplete.
https://codesandbox.io/s/material-multiselect-working-ig9s8 . How can I infer/determine how good it is currently. Didnt see any updates in last few months roadmaps...
From Material-UI website:
"The main difference between the lab and the core is how the components are versioned. Having a separate lab package allows us to release breaking changes when necessary while the core package follows a slower-moving policy.
As developers use and test the components and report issues, the maintainers learn more about shortcomings of the components: missing features, accessibility issues, bugs, API design, etc. The older and more used a component is, the less likely it is that new issues will be found and subsequently need to introduce breaking changes.
For a component to be ready to move to the core, the following criteria are considered:
It needs to be used. The Material-UI team uses Google Analytics stats among other metrics to evaluate the usage of each component. A lab component with low usage either means that it isn't fully working yet or that there is a low demand for it.
It needs to match the code quality of the core components. It doesn't
have to be perfect to be a part of the core, but the component should
be reliable enough that developers can depend on it.
Each component needs type definitions. It is not currently required that a lab component is typed, but it would need to be typed to move to the core.
Requires good test coverage. Some of the lab components don't
currently have comprehensive tests.
Can it be used as leverage to incentivize users to upgrade to the latest major release? The less fragmented the community is, the better.
It needs to have a low probability of a breaking change in the
short/medium future. For instance, if it needs a new feature that
will likely require a breaking change, it may be preferable to delay
its promotion to the core."
https://material-ui.com/components/about-the-lab/
Summary
So as I understood it, lab components may not be tested, typed or aren't widely used. In addition, they might have poor code quality or are pending features/refactors that might radically change the API.
I just started using flow-typed definitions for my popular libraries in a React Native app such as React Navigation, but I find it quite hard to find the documentation on types and how to use them. I'm still getting errors in my IDE and I feel like Flow is more wasting my time than adding value to my developer experience because I've to lookup for the types all the time (and sometimes don't even find an answer). Any advice about that ?
A complex web application using many npm modules is very rarely going to be strongly typed throughout. The goal of strong typing in JS is largely to have as much typing as is feasible or even reasonable. Modules which do not have libdefs will come in as any and that's okay. Obviously it would be great if everything you pulled in had full types, but just given the way that progress is made this is practically impossible. Add to this the fact that the simple act of upgrading flow will often introduce more caught errors to your codebase, and you end up having to accept that typing is a progressive process, it shouldn't really be a blocking one.
Now that that's out of the way, you seem to have a number of different sub-questions:
I've to lookup for the types all the time
Not entirely sure what you mean by this, but you might saying it's hard to find types for the package you're using. Make sure you're familiar with how the flow-typed CLI tool works (npx flow-typed), it will help you with searching for and installing compatible libdefs. If you don't find anything for a module in flow-typed then poke around the source github repo and make sure flow types aren't shipped with the module itself. If you come across a package with a .d.ts (TypeScript) file, try converting it to a libdef with flowgen. If nothing proves fruitful, you should probably just forego types and carry on.
In this case, I would actually start my own libdef (npx flow-typed create-stub <package name>) and fill in some basic types as I went. You can start really simple, I have a libdef currently for react-select that only checks one prop of the component, the options prop (I don't remember why I have this, however :P). Again, progressive typing is the goal. Checking that one prop is actually really nice compared to checking none.
I find it quite hard to find the documentation on types and how to use them
There's generally not real documentation for libdefs in flow-typed unless it's written by the package author somewhere. I usually read the libdefs themselves, but if you find usage confusing I would recommend looking at the tests associated with the libdef. You can also dig through any relevant issues or PRs to find usage examples.
sometimes don't even find an answer
Add a $FlowFixMe and come back to it later if it slows you down too much. All of these things will become much more manageable as you become more accustomed to flow and strong typing in general, and both flow and libdefs are constantly improving.
I'm still getting errors in my IDE
If you can't fix them, add a $FlowFixMe and come back later. Flow actually has a tool included in its source code that has a utility for adding $FlowFixMe for every error, but as it's not currently shipped to npm you have to clone the source to use it.
I have been using both in my projects and sometimes I find the need to use a Material UI component within a bootstrap component and the UI displays as I would expect. I have been advised though not to use this approach. Is there any reason why since both are using the grid and can be flexed?
I tend to be verbose so I'll put the concise answer up top here:
Conclusion:
Whoever said it was bad to use both might just be expressing their
opinion, in reality saying it's bad to use both really lacks context
in what you're designing. #user3770494 made a very good point- but the
point, while valid and truthy about the build size, it does depend on
the scope of the application. If it's an intraoffice application with
everyone on a fiber network local it'd all be cached in memory
anyways... but (not that you know me) I would not judge you negatively
if you mixed them together-- unless it was for a MAJOR million user
application to run on mobile (an very low devices), desktop, and other
devices around the world requiring real(ish) time updates, and
streaming dynamic content with 10000s of active users at any givin
time 24/7.
In all truth- if it's not life or death-- I'd say use both- and also
do your own. The experience of understanding more then one thing is
better then just "committing to a single solution" for personal
growth.
The rest of this reading is optional - you're welcome :)
I personally have used both in production applications (both together, and independently)... I've also done it all from scratch... (CSS is my least favorite part of job things I do - luckily I have a coworker who is great at it) Here are my thoughts:
Warning: I tend to be verbose.
Disclaimer:
As someone who likes function over form, form is an afterthought that is nit picky for clients to ask about tenuous little changes. I am going to try to leave my opinion on "how each option looks for feels" out of this as much as I can.
Also I'm looking at your question in a current choice I'm making- which is using ReactJS / create-react-app to make "demo" projects for touch screen embeaded systems- so I am going to roll out half a dozen mock programs for demos nothing that really does anytihng exactly (CCscanner, barcode scanner, gps, webcam integration, fun stuff like that). So I'm researching what will be easist for me to just commit to for this "beacuse I'm bored and got a pi3b+board for fun).
Answer:
If you have the time, dedication and resources, there is really
nothing wrong with mixing them together. But you just need to think
about the time/cost/benifit of it. DIY to make the end user happy-
even if you mix them. Totally yourself is remaking the wheel- but you
can always pull in boostrap styles etc.
The inherent risks is that if you use both- make sure you don't "Mix them" to much- because then you will always have issues with trying
to ever do version changes on either one.
I like a lot of MaterialUIs things, but I honestly dislike how a few things look (style wise by default)- functionally I like it better
then bootstrap, but at the same time, I do not like MaterialUIs React
programming style (as a purist who hates CSS But knows how important
it is- having to use !important ever ever ever ... is big big big
nonononononononon) compared to whatever way my coworkers and I use
for conventions. Not saying it's better or worse then my own
preference- but a few things about it really irk me (even if they are
done for good reasons).
Bootstrap has a lot of choices to use for- I like how it looks better, I like how it plays with ReactJS better- but there is
reactstrap vs. react-bootstrap (which is why I found your post trying
to figure which one to use for this demo thing I'm doing).
Most recently (for production projects) I do try to stick just with one but normally I'm making systems that are function over form. So
they don't really care that much about the UI elements, it's about
how to use it not make it pretty. So I stick with using a single one
just to make my job easier- and usally still override styles myself
... if the original styles piss me off. But I do not stick with one
because "It's bad form to use both" I just stick with one for that
reason mentioned above. I'd actually say if bandwidth is not an
issue- it's quality to use both- but only use the parts of them that
you actually use.
(I noticed someone once importing full jQuery when the only thing that they used from it was $.ajax (all be it a lot but still) ... I was like... is that not overkill?!) -- So if you use both and want to keep things slim- just make sure on compilation you're only importing what you're using. Pythonically I'm saying- never use import * from module (however you express that in Javascript as a concept - webpack/gulp/whomever should take care of most of that for you). Assuming you're using ES6/7 style Javascript.
I encountered this scenario recently and opted to use both but for specific tasks. With it being a responsive web app Bootstrap made the most sense to use for the layout and Material UI for the widgets (just my personal preference).
You can definitely use both but you should be aware of the following:
There will be a lot of overlap in offered features unless you take time and effort to manage it by carefully picking elements from each of those libraries. And even then you will face situations where you can't avoid overlap. This basically results in a bigger bundle.
You will have to maintain theming variables for both systems to have a consistent presentation across your app. Even then, there will be situations like where your table checkboxes look different from your form checkboxes because they are from different libraries.
You have to learn and understand both of the systems. It means sometimes it'll be harder to find what's causing a certain bug. You'll also be spending more time deciding which library to use for which component.
Overall, it's more work for you to work with two different systems and a higher chance of things looking inconsistent. That said, mixing in things like a grid system with limited theming might not be too bad.
If possible, I highly encourage you to choose one system and stick with it.
Using both will increase your production js size.
Material Ui and bootstrap both provide components with basic styles like buttons so choose one.
You can use bootsrap grid for structure only or even go with flex.
Here are the numbers
min+gzip 26k
gzip 90k
original 450+k
And React doesn't have many features in it's documentation. Why is it so big?
I have a feeling that it's the implementation of lightweight DOM. But I want to be sure.
React does quite a bit! The biggest nonobvious part of React is probably the events system -- not only does React implement its own event dispatching and bubbling, it normalizes common events across browsers so that you don't need to worry as much about it. For example, SelectEventPlugin is a built-in event "plugin" which provides an onSelect event which behaves the same way in all browsers.
The virtual DOM implementation does take a decent amount of code as well; a lot of effort is spent on performance optimization, which is why the unminified version includes ReactPerf, which is a tool for measuring rendering performance. In updating the DOM, React also does some convenient things for you like maintaining any input selection and keeping the current scroll position the same.
React also has a few other tricks up its sleeve. One of the coolest is that it fully supports rendering a component to an HTML string even if you don't have a browser environment, so you can send down a page that works even before JS is loaded.
What are you comparing React against? react-15.0.2.min.js is 43k (gzipped), but jQuery is 33k while ember-2.6.0.prod.js is 363k (also gzipped). Obviously these frameworks don't do exactly the same things but they do have a lot of overlap, so I think the comparison is reasonable.
If you're worried about download size, I wouldn't worry too much about JS code contributing to that. Here's an ad which I see on the right side of my Stack Overflow page right now:
Its download size is 95k -- I wouldn't think twice about including an image like that in a page because (even if I was worried about performance) there are usually so many other performance-related things to fix that are more lucrative.
In short, I don't think React is that big, and what size it does have comes from the many small things it does to help you out. You cite React's small API as a reason that React's code should be small, but a better question might be, "How is React's API able to be so simple given all the things it does for you?"
…but that's a totally separate question. :) Hope I answered your question -- happy to expand if I didn't.
A couple of thoughts.. I had some of the same concerns with it's size, but after using it, no joke, I would use it if it was 5MB in size. It's just that good. That said, I did decide to reduce as many dependencies on other libraries as possible. I was using jquery for two things.. ajax and the automatic ajax response and request handling (beforeSend, etc) that would handle when a token was in a response after login, and then make sure every ajax request added it to the Authorization header before sending. I replaced this with a super small simple bit of native javascript. Works great. Also, I was trying to use _underscore. I've replaced it with lodash, which is smaller and faster, although presently I am not using it so may remove it altogether.
Here is one article, of many on google, that I found that has some alternatives using native JS over jquery.
http://www.sitepoint.com/jquery-vs-raw-javascript-1-dom-forms/
I know it has great out-of-the-box features but is it easy to customize?
Like when I query stuff from the database or change css layouts.
Is it faster to create my own modules for it or just go on and write everything from scratch using frameworks like Cake
I'm currently working on an Elgg-based site and I absolutely hate it. The project was near completion when I stepped in, but the people who created were no longer available, so I took it over as a freelancer.
As a personal impression, you are much better off writing the app from scratch in a framework. I don't know if the people before me butchered it, but the code looks awful, the entity-based relationship model is wierd to say the least and debugging is horrendous. Also, from my point of view, it doesn't scale very well. If you were to have a consistent user base, I'd be really really worried.
It keeps two global objects ($vars and $CONFIG) that have more than 5000(!) members loaded in memory on each page. This is a crap indicator.
I've worked extensively with cake. With Elgg, for about a month in a project that is on QA stage right now.
My advise is: if you need something quick with a lot of features and you only need to customize a little, go with Elgg.
If you're going to customize a lot and you can afford the development of all the forums, friends, invites, etc. features, go with Cake or any other MVC framework.
I have been working on a Elgg site for the past month or so, its code is horrible, however it's not the worst I've seen :D. it's not built for programmers like Drupal is :D. But it's not too bad. Once I got a handle on the metadata functions and read most of the code I was able to navigate it well and create custom modules and such.
What would help immensely would be some real documentation and explanation of the Elgg system. I don't think that's going to happen though :).
Out of the box there are a few problems, there are some bugs that haven't been fixed for a while and I've had to go in and fix them myself. Overall, you can make it pretty and it has some cool functions, but i wouldn't dive in until i had read the main core code to get a handle on what's happening on the backend.
Oh and massive use of storing values in globals. and a crap ton of DB calls (same with Drupal though).
i wonder if the use of storing everything, and i mean everything for your site in the globals will really hinder the server if you have a massive user load.
If you want to build a product based on a social networking platform/framework then Elgg is definately a good way to go. The code is not that bad if you actually look before leaping and doing what elgg expects. You go against its processes and structures and it will leave you beaten by the side of the road.
Developing modules/plugins or editing CSS is easy and Elgg does give you great flexability to basically build your own product ontop of it. Dolphin, as comparrison, does not allow you to do anything outside of what it expects you to do.
If you however just need a framework (not primarily for social networking etc) with some user based functionality then i suggest Cake, or if your project is HUGE then maybe Symfony or Zend. They all have plugins you can download and use/hack which would be easirer to adjust for personalised needs.
To show what you can do with elgg here is a site Mobilitate we built with Elgg 1.7. This is a very complicated website and was built ontop of Elgg.
We are starting a new project with Elgg 1.8. The new version is a major improvement they have made a lot of elements easier, incorporated better JS and CSS implementation/structure and have better commented their own code.
Elgg's database schema is horrific. They've essentially implemented a NoSQL database in SQL. It completely defeats the purpose of using a relational table structure.
If you can ignore this, and aren't doing much customization, you might be OK with Elgg. If not, STAY AWAY.
I've been working with Elgg for over a year. It is easier to customize than it would be to build something from scratch using a framework like CakePHP. I tried CakePHP and found it even more complicated than Elgg.
It is difficult to query the database due to the entity-based relationship model. You should use the build-in methods for accessing data. However, I have written many queries to double check on what is actually stored in the database.
You cannot change layouts using CSS alone. You have to deal with the various Elgg views. But CakePHP uses the same Model/View/Controller MVC concept so that would be just as difficult.