I have a React UI library that has a documentation site with interactive examples that run with CodeMirror + Babel.
The examples are written within the library repository itself and are read by the client side JS (CodeMirror) of the documentation site when the page is loaded.
I would like add tests to the project's CI server that runs when pull requests are created in order to guarantee the documentation site examples will run without deploying the documentation site itself.
What would be the best way to go about this?
Could it be implemented within a test framework like Mocha? I'd assume you could setup CodeMirror with text inside of it and then search the DOM for nodes that rendered.
Would a try/catch statement be needed? I've not found a hasError API within CodeMirror. Errors tend to bubble up the into the console and block further rendering on the page.
Related
I have a request from a client to implement deep linking in our React application whereby clicking a link will take them directly into the installed app (potentially to a certain point but not sure on that yet).
To my understanding react-native and react-navigation both handle this as part of a feature set within "Linking" that they offer. However it seems excessive to import a framework just for deep linking (perhaps not though).
After googling I can only really find references to deep linking on react-native or react-navigation.
What is my best course of action?
Let's get to some basics first, then it will be clear.
In modern SPA's, say with React, it's common for the SPA to handle navigation itself. You need to use browser's history API. It's because your SPA is just a single index.html with bunch of js code, so it sort of virtual, every page is constructed by your app. In order to not reinvent a wheel, its easier to use some library for that, say react-router-dom.
But then everything works as expected, and you have deployed your app. When user wants to get some deep page, say, https://my-awesome-app.com/deep/page/1, browser will just send a request to a server, asking: "Please, server, give me a page 1.html, in folder page, in folder deep". But server doesn't have that file, because it has literally one index.html, because its a SPA application. Then we need to tell the server to re-write all deep routes to index html, here is an example for my app hosted on Netlify:
[[redirects]]
from = "/*"
to = "/index.html"
status = 200
When user will ask for that page, server will 'redirect' that request to the index.html and my react-router-dom will figure out which 'PageComponent' to render based on that path.
So, you can implement routing in your app yourself, probably using browser's History API, but I guess it might be easier to use library. But it's your call.
On the other hand if your app is not an SPA, the story might be different, because say in NextJS routing is implemented in framework itself, and if used deep linking would require different setup depending on how app is deployed.
Deep-linking is handled largely by Apple and Google server-side
https://www.adjust.com/blog/dive-into-deeplinking/
React-native provides extended functionality for deep-linking within mobile apps but normal web-applications there is no need to implement it there. Use universal links or Google specific links as standard linking within your web app to enable deep linking
I am trying to write tests for one of our rich text components which was implemented with slate js editor in react js. So when writing tests, I am retrieveing the element div[contenteditable='true'], but not able to simulate events like change, blur, focus. The handlers attached to editor component are not getting called. I tried multiple combinations, but no luck. Can someone please help on this? Is it possible to simulate events for contenteditable element using testing library (contenteditable is implemented using slatejs)?
Like you've discovered, contenteditable isn't supported by JSDOM. React Testing Library (RTL) is built on top of JSDOM, so it's not possible to test the Slate editor properly with RTL until JSDOM implements support for contenteditable.
Use a browser automation library together with Testing Library
Your options are then to use a tool that creates a real browser context. Testing Library have integrations with many tools that do exactly that: TestCafe, Cypress, Nightwatch, Puppeteer.
You can also use the above tools on their own, without Testing Library.
I've solved this using Puppeteer, and there are two approaches:
Run a local server and tell Puppeteer to go to something like localhost:3000
Set the content directly with page.setContent(htmlString)
(1) is the most common, and you'll find many guides for this since it's a common approach for end-to-end testing (google search).
(2) is a little trickier because you will have to transform and bundle your source for each test, and then inject it as HTML into the browser page. I prefer this approach because the testing experience is much more similar to using RTL. I've created a repository with an example of this setup with the Slate editor here: https://github.com/marcusstenbeck/puppeteer-react-testing-template/
Till now I worked on Java based web applications and recently started working on ReactJS applications. Below questions are running in my mind and I appreciate your help in providing solutions for below questions:
I came to know that Babel is going to convert the ECMAScript2015+ code and the JSX code to ECMAScript2015 so that the browser will understand it. So does this translation will happen when we compile the React project using "npm"? And if it happens during the compilation, does the Babel will convert the entire code in the whole project at a time (or) will Babel converts the file which is requested by the client?
Once after creating and developing the React code, we are using Node software to install all the required dependent libraries which are used in our React code and also "npm start" command to start the react application. So here I want to know if NodeJS is the server which runs the React applications and without NodeJS we cannot run React application as a standalone?
When we take Java based web application, that Java application will be running in a server computer and Jboss or Websphere Application Server etc... are responsible of running the Java web application EAR project. Then when a client makes a request to any resource in the EAR, then the server will take the request and send the response as an HTML to the client.
In the same way I want to know how this request response cycle works in React Application? For example, if the react application is running in a server computer and NodeJS has started the React Application in the sever computer, then when the client invokes the React application using the URL corresponding to the React Project, then what the server is going to send back to the client/browser? As Babel will convert the React application to the plain JavaScript (which is understandable to the Browser) and so does the server will be returning the Javascript back to the client?
If the server returns the Javascript code to the client/browser, will the server returns back the Javascript code of the entire React project (all files) to the client or will the server returns the Javascript version of ONLY the request file?
React is a front-end library, which runs in the browser. Like any other frontend library (jQuery, etc), it is happy to be served by any old webserver – Apache, NGINX.
The react application will communicate with the backend in the form of REST API calls, which will only produce the dynamic data rather than the HTML.
The HTML is drawn using the JSX on the frontend (https://reactjs.org/docs/introducing-jsx.html)
The compilation happens every time you start your project (say npm start) or, if the project is already running, on any saved changes, it will recomplile every time as well as give you any errors found during compilation.
Yes, the NodeJS will be the one serving content. Technically, you can still use React as standalone. See This tidbit in official ReactJS Documentation
I'm not really great with technicalities behind React inner workings, so anyone competent feel free to correct me on this, but your server will serve JavaScript code to your browser already working and compiled fully so that even if the React server stops running (terminated or any other reason), you will still be able to work with most of the application since the data has been already loaded. There may be libraries/packages that allow lazy loading of components, but that depends on your usecase, I guess.
See my final bits in the previous point.
Hope this helped you in some way
I watched Google's conference on SEO and they suggested to use Dynamic Rendering for JS built applications (React, Vue, etc). One of the tools to achieve this is with Puppeteer JS.
I need to create an app that relies heavily on SEO so Server Side Rendering (SSR) is extremely important.
I know that Next JS by default accomplishes SSR, but can I do the same with Puppeteer + Create React App? What is the difference between Next JS and Puppeteer in terms of SSR and Dynamic Rendering, and which one is better for SSR?
In short,
Next.js is a node framework. You use it to write code, i.e. build your application.
Pupetteer can be considered a tool. It comes bundles with Chromium which is practically a browsers equivalent to a testing environment. You writes tests via pupetteer to run scenarios in chromium.
I've provided an over-simplified explanation for those who want it. Shmotam gave a brilliant answer if you want depth.
Difference Between Nextjs and Puppeteer JS is very very simple.
Next Js :- It is React Framework for server side rendering those help in SEO, Optimized for Discovery , Lightning Fast Delivery.so ,very simple word is SSR. For Link https://nextjs.org/#features
Puppeteer JS it is Developed by Google and this is used for End to End testing of your application like selenium.
Both are completely Different and purpose are also different.
Headless Chrome enables "isomorphic JS" between server and client. It's a great option if your library doesn't work on the server (Node). Example for it is lit-html which it's core feature doesn't work outside the browser.
The difference is huge in terms of features.
Next.js offers some nice features that Pupeteer doesn't.
Hot reloading client & server
Automatic code splitting
Built-in CSS support, CSS-in-JS
Fetching data and component lifecycle
and more.
Some feature of Pupeteer:
Generate screenshots and PDFs of pages.
Crawl a SPA and generate pre-rendered content (i.e. "SSR").
Automate form submission, UI testing, keyboard input, etc.
Create an up-to-date, automated testing environment. Run your tests directly in the latest version of Chrome using the latest JavaScript and browser features.
Capture a timeline trace of your site to help diagnose performance issues.
and SSR apparently...
So you can see the major difference these two tools have.
Next.js is opinionated but aims to do SSR with react and builds on that concept;
Take into account that SSR with Puperteer in relatively new whereas community adoption of next.js is already mature with nice set of examples with different tech stacks.
nextjs is the powerful framework that supports ssr (server side rendering) and seo friendly Google search engine.
The react of interpretation is that the component is called after each state change. but nextjs load component and call getInitalProps first time, so view page source you can see data loaded
Puppeteer is used to make bots which works at backend.
NextJs is used to build Full Stack Website. And may be it will soon be available for React Native to make mobile apps.
I'm starting building a react native application for both iOS and Android. I've read through the documentation of react native application, but there is one thing now I do not understand:
Is react-native app fully native application?
They say in react-native, that it would be. Then why am I asking this question? Well, I found the reason to ask the question through https://github.com/Microsoft/react-native-code-push. According to code push, they are able to dynamically update the application. And this is done by updating the javascript part of the application. But wait, if the application is real native app, then in the final version of the app there shouldn't be any javascript, am I right? So how are they doing it? Are they compiling the application at code push servers, and then sending the compiled app to the user or what? This really worries me that the react-native app is really not fully native app.
The CodePush plugin helps get product improvements in front of your end users instantly, by keeping your JavaScript and images synchronized with updates you release to the CodePush server. This way, your app gets the benefits of an offline mobile experience, as well as the "web-like" agility of side-loading updates as soon as they are available. It's a win-win!
Also, the reason I'm doubting this is because they say also in code-push documentation, that they are unable to update the native part of the react-native application:
Note: Any product changes which touch native code (e.g. modifying your AppDelegate.m/MainActivity.java file, adding a new plugin) cannot be distributed via CodePush, and therefore, must be updated via the appropriate store(s).
If the react-native app would be fully native, then in the end, all code should be native code. So I don't really understand why would it be harder to update the native native code, than the code that has been compiled to native?
If you change only code in /src/ folder (JS code) and without adding native modules
you can use CodePush to update your application.
If you change code in /src/ folder (JS code) and add some natives modules, you can't use CodePush to update your application.
You're JS code is compiled and read by native components. That's why you can update the JS layer.
If you take a look into your .ipa file and open main.jsbundle (unminify required) you can see your JS code. example: