Blog posts by Sam K @ MtE

Blog posts by Sam K @ MtE2021-11-19T13:52:04.0000000Zhttps://world.optimizely.com/blogs/sam-k--mte/ Optimizely World Adding React to an Optimizely UI - Part 2In <a href="https://dev.to/skmte/adding-react-to-an-optimizely-ui-part-1-31kh">Part 1 of this series</a>, I gave a start-to-finish overview of how we at <a href="https://www.madetoengage.com">Made to Engage</a> integrated a React application into an Optimizely ASP.NET MVC website. I'd like to delve into several aspects of the process in more detail over the next few parts, starting with the choice of React itself and the specifics of how we actually implemented it, given there were (as there always is with anything front-end...) several options. <h2> <a href="#why-a-frontend-framework"> </a> Why a Front-End Framework? </h2> JavaScript is easily the most flexible way of implementing a performant, user-centric experience in a browser. Your HTML gives you structure, CSS makes it pretty and JavaScript manipulates it as necessary. At some point, the amount of JavaScript code increases and the amount of manipulation required - even with the help of some still very popular libraries... cough...jQuery...cough - reaches the point of being unmanageable and unsustainable. FE frameworks have, in recent years, really risen to address these limitations. Taking on a project to do exactly what these frameworks are designed to do really meant it was a no-brainer to go with one. <h2> <a href="#but-which-one"> </a> But which one? </h2> The decision of which front-end framework to build on given a reasonably blank slate is always a challenging one. The stereotype of the front-end development landscape changing every 15 minutes is not entirely undeserved - the choices are, indeed, ever more numerous. But the big name players are still <a href="https://reactjs.org/">React</a>, <a href="https://angular.io/">Angular</a> and <a href="https://vuejs.org/">Vue</a>, in my opinion (and I fully confess there was a lot of my opinion in the decision phase here!). Other noteworthy candidates were <a href="https://nextjs.org/">Next.JS</a> and <a href="https://svelte.dev/">Svelte</a>. However, for reasons including (but not limited to): <ol> <li>In-house developer experience</li> <li>Learning curve</li> <li>Community support and documentation</li> <li>Training availability</li> <li>Package library diversity</li> </ol> ...we chose React. And then we added <a href="https://www.typescriptlang.org">TypeScript</a>. As I mentioned in Part 1, I've been someone who was - despite my years of experience and interest in new development tools - actively resistant to adopting TypeScript. But I'm willing to admit I was mistaken. It has definitely grown on me. The supporting tools in IDEs like VS Code are really excellent and the assistance you get when developing actually does help significantly. I can't see us starting any significant piece of JS development in the future without using TypeScript. I have no doubt that: <ol> <li>perfectly valid arguments could have been made for using a number of other frameworks</li> <li>we would have successfully produced a solution using any one of those number of other frameworks</li> </ol> But React it would be for us for now. <h2> <a href="#integrating-with-net"> </a> Integrating with .NET </h2> Since we remain somewhat constrained by a traditional MVC architecture and a UI rendered using Razor views, we needed a way to integrate the React app into the site. One potential option would have been to use <a href="https://reactjs.net/">ReactJS.NET</a> - a platform almost specifically built to do what we were trying to do. But the coupling of Razor and React required by this tool just felt "wrong", and would have left us inseparably tied to React (<a href="https://world.optimizely.com/forum/developer-forum/Developer-to-developer/Thread-Container/2020/5/using-reactjs-net-is-dxp/#222699">a view also expressed by the Optimizely team themselves</a>). Given our "proof of concept" stage, maintaining the ability to swap out one framework for another one in the (unlikely-but-you-just-never-know) event of reaching an insurmountable road block was important. <h2> <a href="#-raw-createreactapp-endraw-"> </a> <code>create-react-app</code> </h2> The de-facto standard when starting a new React application is to open a terminal and run <code>npx create-react-app</code>. Again, we decided against this. Whilst this app does indeed give you absolutely everything you need to create, build and deploy a React application, it includes a bulk load of features that we didn't expect to need and we weren't creating a Single Page Application (SPA) - something <code>create-react-app</code> is very much angled towards. Our app was going to be a fully built-by-hand endeavour. Starting with a brand new working folder and <code>npm init</code> and a <code>src/index.tsx</code>, off we went. 2021-11-19T13:52:04.0000000Z

Blog post

Adding React to an Optimizely UI - Part 1At <a href="https://www.madetoengage.com">Made to Engage</a>, we build solutions on the <a href="https://www.optimizely.com">Optimizely Content and Commerce platforms</a>. We have a significant number of clients using Optimizely Content up to v11 and we've been considering how we might be able to deliver some of the more complex and heavily interactive user journeys our clients need by leveraging modern front-end frameworks. In this post, I want to walk you through how we've recently architected the introduction of React to part of the site for one of our largest e-commerce partners. This is the first part of a series looking at how we approached this challenge as an organization in which I'll summarize the technologies and solutions. In subsequent parts, I'll break down some of the key aspects in more technical detail - keep an eye out for these over the coming weeks. <h2> <a href="#whats-the-motivation"> </a> What's the motivation? </h2> Front-end frameworks are obviously becoming huge in terms of developing web solutions and user interfaces. With Optimizely Cloud being built on a server-based ASP.NET MVC architecture, there's a challenge to leveraging some JavaScript tools. But user expectations are growing ever higher. Performance, personalization and quality experiences are essential for any site and significant improvements in these areas can have huge impact on conversions in an e-commerce context. As an agency, we have the design and UX expertise to know what works in these areas and this exercise was about how to implement those ideas technically. <h2> <a href="#what-would-we-need"> </a> What would we need? </h2> So how would we inject a React app with all its dependencies on CMS content and configuration into the existing site and have it render on-screen? We would need: <ol> <li>The React application itself</li> <li>A placeholder within the Razor views of the MVC site in which to inject the React code</li> <li>A mechanism to provide the required data to the React app</li> <li>Support for server-side rendering (SSR)</li> </ol> I'll go into the thought processes (e.g., why React?) and structure of these individual items in further posts throughout this series. <h2> <a href="#the-react-app"> </a> The React App </h2> Items 1 and 2 were intrinsically tied. We had to have a React app and then confirm that we could get it to render in the context of using Razor views. On the surface, this seems pretty trivial - you just need some JS files declared as a bundle and included in your Razor! But this was key to deciding if the approach would work long-term, so we had to prove it as a concept. We also had to decide whether or not to use TypeScript. With 20+ years of writing JavaScript under my belt, I've been a slightly hesitant adopter of TypeScript, but it honestly feels like starting any significant JS development project nowadays without it is churlish. TypeScript it was - more on that in a later post. We created a very simple app initially to ensure it could be embedded into the site as we wanted. Since "create-react-app" generally focuses on SPAs and includes a lot of features we didn't expect to need, we decided against it but instead hand-crafted the packages and files we needed. For context, our first <code>index.tsx</code> app looked something like this: <div class="highlight js-code-highlight"> <pre class="highlight jsx"><code>import React from 'react'; import ReactDOM from 'react-dom'; import App from './app'; ReactDOM.render( <App />, document.getElementById('react-app'); ) </code></pre> </div> Using Webpack, we built this to an existing folder within the .NET web application to make it easily referenceable using the following partial config: <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code>module.exports = (env, argv) => { return { entry: { 'react-app': './src/index.tsx' }, output: { filename: '[name].js', path: path.resolve(__dirname, '../static') }, resolve: { extensions: ['.ts', '.tsx', '.js'] } } } </code></pre> </div> We quickly reached a point of having a compiled JavaScript file that we could reference in our Optimizely Content site. <h2> <a href="#razor-placeholder"> </a> Razor Placeholder </h2> The next task was to add something to the Razor views to get the app to appear on screen, leading us to this: <div class="highlight js-code-highlight"> <pre class="highlight html"><code><div id="react-app"></div> @Html.VersionedJs("~/static/react-app.js") </code></pre> </div> With a quick <code>npm run build</code> of our React app and a spin-up of the Optimizely MVC site, we browsed to the necessary address. Et voilà! A React app rendered inside an Optimizely view. <h2> <a href="#injecting-data-populating-state"> </a> Injecting Data (Populating State) </h2> The most important element of making this work was ensuring that the React app had the required data. This would obviously be built and prepared by the back-end C#, but how best to get it into the app? Really, it comes down to one of two options: <ol> <li>Render the data in some way on the page (e.g. hidden field) and consume it within your React start-up.</li> <li>Mount the React app and trigger an immediate callback to fetch the data.</li> </ol> The trade offs here are about performance and user perception of speed. We went for the former initially, purely because a lot of the work to build the data was done on page load behind the scenes, so it didn't really make sense to get a blank, placeholder UI on screen before then re-requesting much of the already built data. We may review that over time as our app grows. Using <a href="https://redux.js.org/">Redux</a> for state management (which will be important in the SSR section below), our app instantiation code expanded to look like this: <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code>import React from 'react'; import ReactDOM from 'react-dom'; import { Provider } from 'react-redux'; import App from './app'; import { initStore } from './redux/store'; const dataBlob = (document.getElementById('initial-state') as HTMLElement).value; const storeData = JSON.parse(dataBlob); const store = initStore(storeData); ReactDOM.render( <Provider store={store}> <App /> </Provider> ); </code></pre> </div> <h2> <a href="#server-side-rendering"> </a> Server Side Rendering </h2> Given this React app was being included in a major e-commerce solution with significant SEO foundations already in place, it became clear we would need to implement server-side rendering (SSR) of our React app to maintain those high scores and visibility. This was definitely one of the more interesting aspects of the overall project and will be covered in detail in a later post - it turned into a very expansive aspect, too! <h2> <a href="#summary"> </a> Summary </h2> So, that's the overview - a proof of concept idea to include a significant, standalone React element in a long-established ASP.NET MVC application, with state management and SSR to support continued SEO efforts, taken through to a production-quality implementation. In the rest of the series, I'll go into more detail about the different parts of the solution and hopefully be able to share something of how the changes have been received by our client and their customers once released. 2021-11-05T14:19:37.0000000Z

Blog post