Month: May 2020

As outlined previously I’m taking some steps toward learning and using the React Javascript library to develop some web interfaces/applications. The following documents progress toward writing that first application, which is largely confined to develop an initial mock-up and then learning more about the “React way”.

Developing a mock-up

The React site provides an introduction the main concepts of React. Number 12 of that list is titled “Thinking in React”. It starts with a mock up. A mock up also fits with an agile tendency to want to maximise feedback and iteration. I need one to share with my “clients”.

This is where React Proto could enter the picture. It’s an Electon-based app that supports prototyping React applications. Sadly, however, it’s reality doesn’t match my original assumption. You need to create a mockup image first. Then React Proto can be used to outline the React components within that image and then produces code.

Which has me looking for a web prototyping tool and stumbling across Justinmind Prototyper. Which looks like being a very slow download. Eventually downloaded and after some initial struggles groking the tool a rough prototype developed. Showed to someone. Got some initial feedback.

Next step use – npx create-react-app gradcheck – to create a skeleton React app. But a skeleton that doesn’t include any knowledge of the app I’m designing and the React components I’ll need to write for it.

This is where React Proto comes in. Using it I

1. Import a screen shot of the HTML template created using the Justinmind prototype.
2. Mark up that image using React Proto to identify each of the required components, including configuring a few options.
3. When finished, export that data into my existing gradcheck application.

Ending up with a folder of jsx code ready for me to fill in details.

Sadly, it doesn’t quite update everything. Running – npm start – to view the app still gives the default create-react-app view. Do I know enough to make the change?

That’s a no. Time to take baby steps

Main concepts of React

Next step is to work through the Main Concepts “guide” for React, including updating some Javascript knowledge.

And then we’re into JSX. The apparently strange, almost PHP-like approach to mixing HTML and code. However, unlike PHP, React does provide some separation of concerns. Rather than functional separation – rendering and UI logic – React separates concerns into separate components. For me, this echoes of the argument against functional decomposition proposed by “The Method” from Righting Software. Need to read and think more about this.

Nice intro to JSX. Definition of React elements – the output of React.createElement calls and JSX – which are objects that describe what to see on the page. Used by React to construct the DOM.

Rendering elements

Onto Rendering Elements and starting with the idea of elements being used to make up components.

React applications are embedded into HTML pages via a particular (web) DOM node. There can be multiple. React handles the “rendering” of React elements into those DOM nodes.

React elements – its children and attributes – can’t be changed. To update the UI you have to create a new element and render it. But the React DOM is smart enough to only update what’s changed.

The focus is on what the UI looks at any given time, rather than how to change it. Apparently doing this eliminates a class of bugs. Will need to think on that.

Typically the render function is called only once (more on this to come)

Components and props

And now onto components, which are apparently like JavaScript functions. React components provide the reusable bits and can be designed in isolation from each other.

Thinking of them as functions, they take input. Called props. And return React elements. Hence where JSX enters the picture.

They can be defined two ways. As Function or Class components. Function components are functions. Class components are defined using JavaScript classes. Apparently each have strengths and weaknesses. But I’ve seen some recommended functions. And create-react-app appears to be going there by default.

The code produced by React Proto is using a different structure. Hence my problems above. More to learn.

React components must start with a capital letter. Otherwise they are seen as DOM tags.

Once the components are defined, you get the benefit of being able to reuse again using HTML.

e.g. the following from my playground during this process. The function Welcome is defining a new (very simple) React component. It takes props and uses JSX to return a React element(s).

This component is then used twice in the create-react-app App component. Which is described as typical React practice. See the two tags <Welcome name=”…

The power comes when the components are much more powerful than Welcome.

The trick then is how to decompose a web UI into components. The example on the components page shows that it is much more fine grain a decomposition than I expected.

Ok, props can’t be changed. Functions must be pure in this way. A React requirement.

It is via a new concept State that React components change their output/appearance in response to external actions.

State and lifecycle

How then do you get a React clock component? A component that updates its display as the time changes? Enter State and Lifecycle.

Only a single instance of a class is used per DOM.

The first time a component is rendered into a DOM, it’s called mounting and to tidy up resources there is unmounting.

Which correspond to lifecycle methods such as componentDidMount.

The state data member of a component holds state. It can/should only be changed using the setState function. This is how React knows that changes have occurred and thus should looking into running render again.

setState may be asycnchronous. Placing limits on how props and state can be combined. Requiring a second form of setState passed a function.

Status is encapsulated. No other component can know about if/what state a component has.

Handling events

What about handling user interface events?

Some similarities with JavaScript. But differences, including:

• Using camelCase for names
• Passing functions
• Having to explicitly call preventDfault

Will need to revisit this in anger when working on a project.

Conditional rendering

It appears that conditional rendering is the idea of encapsulating different states in different React components. Then using conditionals to choose which element to render.

If an element returns NULL, then the component will not be rendered.

Lists and keys

And onto data structures – lists and keys. Particularly useful for generating lists of repeated elements. E.g. lists, table rows etc. JSX notation allows some powerful combinations.

But useful if these have keys (for React).

Forms

Apparently Form elements react different in react. Unlike other HTML elements, form elements maintain some internal state.

Preventing normal submission of a page by the form, requires the use of controlled components.

Which means that the React state of a form element becomes the authoritative source. The component has to control the state of the form element.

Which means that an onSubmit event handler is written as part of the component.

There are also differences for textarea and select to bring them into line with other form elements.

There is a concept of uncontrolled components.

Lifting state up

Sometimes state needs to be shared by several components. The recommended solution is to lift state up to a common ancestor. This entails

1. Moving the bit of state to be shared into the common ancestor.
2. That state is passed as props to the descendants.
3. Pass from the ancestor to the descendants an “onChange” method.
4. When the descendants need to change the value, they call that method.

The idea being that there is a single source of truth for data. One of the components.

Composition versus inheritance

Ahh, the debate of composition versus inheritance. My vague insight into the OO design community was that they’d come down on the side of composition being the generally better approach. Wonder if that’s correct?

Yep, at least for React “has a powerful composition model, and we recommend using composition instead of inheritance”.

There are components (e.g. dialog) that contain others. Advice is to pass children as props. Use your own convention.

Specialisation (Dialog -> WelcomeDialog) also done with composition and props.

Experience from Facebook is that they haven’t seen a need for inheritance.

Non-UI functionality shared between components – not surprisingly – is suggested to go into its own module.

What’s next?

The next page in this sequence is Thinking in React, where I started. I’ll save that for another post where I actually start work on the first version of the Grad Checker prototype.

As the title suggests the aim here is to discover if the React.js library for building web (and other) user interfaces might help address some limitations and add some needed features to the Contextually-Appropriate Scaffolding Assemblage (CASA) idea (Jones, 2019). I’m going to be spending a fair bit of time on this, hence the importance of at least trying to be explicit about thinking it through. Not to mention the value of explicitly trying to make sense of all this and recording the process for later referral.

Any and all comments welcome. Especially technical corrections and disagreements. There’s much more to all of this than I know.

With that caveat, the answer I’ve drawn is that React.js can help improve CASA, and that’s work I’m starting on now.

Following starts with a re-statement of the perceived requirement and outlining limitations of current practice. React is briefly introduced and a comparison done against other possibilities. Finally, there is a dive into the React ecosystem and what it might provide the CASA idea.

What is the requirement?

Last week this tweet from @plredmond had me running down a web-page rabbit hole and stumbling across this list of “Top Research Questions” for the distance education community. A list that was apparently “derived and prioritized by the experts in the field of the 2015 DETA Summit at the ELI Annual Meeting”.

Question #7 – the last question in bold and thus significant? – caught my eye

What are the key components that promote a sustainable and an effective teaching and learning ecosystem?

Not a bad description of my broader interest in digital/online learning within higher education institutions. In last year’s ASCILITE paper I argued that current approaches to enabling effective design for learning (I like Goodyear’s distinction between “learning design” and “design for learning”) in higher education is neither sustainable or effective. The largest reason is the mismatch between the nature of encouraging the on-going development of effective learning and teaching and what can be provided by the current focus on using standard strategic/corporate/leadership techniques (Jones & Clark, 2014).

For example, successfully implementing Microsoft Teams (or Zoom etc) and then offering training on its use will enable the successful completion of an operational plan. It will also enable some examples of good learning and teaching. But it won’t be sufficient for creating (nor a sufficient contribution toward) “a sustainable and an effective teaching and learning ecosystem”.

CASA and Forward-oriented design

My most recent attempt (Jones, 2019) to explore a different answer is the idea of Contextually-Appropriate Scaffolding Assemblages (CASA). CASA are intended to embed necessary design knowledge into a digital technology that is (more easily) embedded into contextually appropriate activity system. An activity system that makes it significantly easier for teachers to engage in forward-oriented design for learning (Dimitriadis & Goodyear, 2013; Goodyear & Dimitriadis, 2013; Sun, 2017) as represented in the following diagram. As argued by others (Dimitriadis & Goodyear, 2013; Goodyear & Dimitriadis, 2013; Sun, 2017) most design for learning stops at design for configuration. My argument is that this flaw infects most attempts to build a teaching and learning ecosystem (e.g. introduce Microsoft Teams)

It’s just not sufficient to implement the learning activity. Instead, active thought has to be given to the type of work that the teacher will need to do: while learning is occurring (including thinking about what the learners will do); while reflecting on how well (or not) that learning activity went; and, re-thinking how that learning activity will work next time. Suggesting that an effective teaching and learning ecosystem will provide active support for forward-oriented design. My argument is that such support also needs to encourage and enable individuals to integrate this support into their context-specific assemblage of practices and skills. To be successful in this it the support also needs to be able to respond to the diversity and volatility of the contexts. Otherwise it won’t be used for long, or at all.

Oh, this also must be achieved sustainably.

Problems with early CASA

As described in the ASCILITE paper (Jones, 2019) we’ve developed and used two example CASA. They have been used in 100s of courses. They fill a need, but they can be better. Some of the current issues

1. The cost (difficulty)/benefit ratio for one of the CASA is still too high.
   One of the CASA remains too difficult/different for some (but not all) people to understand and see its benefits. Hence, they can’t see how it fits with their current assemblages. Instead, some are distracted by the “pretty interface” offered by tools such as Microsoft Sway. A tool that is easy to use, but which at best offers very limited design for configuration and nothing else.
2. Insufficient support for orchestration and reflection.
   In particular, current CASA don’t provide any insight into how and what learners are doing. Meaning next to no support for orchestration and reflection.
3. Insufficient support for customisation and generativity.
   Both CASA currently offer support for a small set of fairly generic activity systems. The reusability paradox suggests that the there is more value in enabling more context specific adaptation.
4. The technology foundation for these CASA is primitive.
   The current CASA were my training projects for Javascript and Blackboard. It shows in the quality of the tech. The limitations are becoming an issue and are one of the major constraints on addressing the above problems.

Lastly, I’ve a project in which I need to develop a graduation checker. A tool that allows students to check when and what courses they need to complete in order to graduate. A tool that requires a more complex user interface.

How to address these problems? What are the options? Well, one is…(and yes I do recognise the apparent techno-solutionism here and have failed to explain why I continue down this route).

React.js

React is a “JavaScript library for building user interfaces”. Its origins are with FaceBook, but I’m trying not to hold that against it. On the plus side, it is open source and widely used. Meaning that there is a lot of tooling available to support React development. There are also jobs available in React development. A plus given the likely COVID inspired collapse in Australian higher education that has a growing attraction and the challenges that poses for people on contracts.

The following seeks to answer these sub-questions about React

1. What about other alternatives? Bootstrap, Angular…
2. Can it be integrated into the existing ecosystem?
3. What support for current CASA might it provide?

Sustainability and reusing design knowledge

Question #3 is important from the sustainability perspective. The CASA idea positions the ability to reuse design knowledge as a key enabler for sustainability. It argues that current approaches to maintaining a teaching and learning ecosystem don’t enable reuse of design knowledge. Too many people are wasting time trying to solve the same problems.

One of the key limitations of the current CASA implementation is that my weak brain had to solve too many problems. One of the strengths of current CASA is that they enable the reuse of existing design knowledge. The ability to draw on and reuse a vast array of design knowledge is important for CASA.

What about the alternatives?

What about Bootstrap?

A lot of people like and use Bootstrap. But, this comparison of Boostrap and Material-UI (a React-based framework discussed below) has me thinking that React offers a better option than Bootstrap. Mainly because it argues that one of Boostrap’s strengths is consistency with “average opportunities for customisation”. For CASA, customisation is important.

React versus Boostrap is really a apples and oranges comparison. Bootstrap is a more complete framework for CSS/HTML and a very successful one. As illustrated in other perspectives and top 15 and top 10 lists of CSS frameworks. React is a library. A smaller scale object. The type of thing React is means much more able to play well with others. Whereas all-encompassing frameworks don’t play well with others. Also, comments suggest that React is easier to try out small and grow.

Perhaps the biggest plus for React is that it focuses on building user interfaces. Providing the View in Model-View-Controller development. The focus with the CASA concept is not to be developing full web applications. It to act as the glue between current systems and practices. The place where additional contextual knowledge is added.

What about Angular and Vue?

What about comparing apples with apples. Apparently it makes more sense to compare Angular, Vue and React.

Angular is from Google. Vue is smaller scale in origins, an ex-Google employee and friends.

For a code-based comparison, here’s a description of writing the same app in both Vue and React. Which initially suggests not a lot of difference, but has me thinking Vue seems to fit my conceptions a little better. But eventually not much to choose between them.

There’s also an article that creates the same simple App using Angular. Angular uses TypeScript which makes it more object-oriented. And ends up with code in a format that’s a bit more familiar to me. However, it’s described as a more heavyweight framework. Bumping up against the issue with Bootstrap above.

Just discovered a site that implements a todo app in multiple different MV* frameworks. If I actually had the time to do an in-depth comparison, this would be very useful. The design of the React version of the app is likely to be a useful inspiration.

With considering just Angular, Vue and React it’s close. However, the sunk cost of the pre-conceived idea of using React will win. Especially given this quote from a comparison of Angular and React

React.js is comprised of tools that help you build components to be dropped into a page

Can it be integrated into the pages that CASA will need to work with?

What about Web components?

Thanks largely to the work of Bryan Ollendyke (@btopro) I’ve become aware of Web components and long put them on my list of tech to grok. The little I knew suggested they’d be a good tool for the CASA idea. Without the slightly grubby feel that a technology that originated at Facebook might being.

According to the React folk, React and Web components are apple and oranges. That they are and can be complementary. Others seem to agree that it’s not React versus Web components. Arguing that something like React might be needed for complex web applications, but not something simpler. React adds state to UI and some other advantages. But in theory these are still interoperable.

Suggesting it’s not currently a question of React or Web components.

Can it be integrated into the existing ecosystem?

One of React’s hyped benefits is that it plays well with others. It doesn’t expect to be the only framework/tool you are using. It can be embedded in web pages produced by other systems. As illustrated by the following two examples working in this WordPress post. They also work in Blackboard Learn, which is currently where the CASA I work on have to live. This also suggests that they will also work in any other future systems or organisation adopts. At least as long as those systems “play well with others”. i.e. not Blackboard Ultra.

Or something slightly more exciting

That’s a yes, but with a bit more to do

What might the React ecosystem provide CASA?

Something like React is a pre-requisite for the next CASA – a graduation checker – which will require quite a complex user interface. A React strong point. Combine that with the large React ecosystem and its integration into Web (and mobile) UI development and it will definitely help the grad checker. The question is what might the React ecosystem offer the two existing CASA.

Card Interface

At its core the Card Interface CASA translates boring, ugly lists of Blackboard Learn content items into a more contemporary interface. It also embeds contextual knowledge, such as on what date does Week 1, Trimester 1, 2019 start? It converts the interface on the left to the interface on the right.

The Card based approach to user interface design is a widely used contemporary practice. You’ve probably seen it on numerous websites. Hence it is a common need for web interfaces. A strength of React is that it encourages the design of reusable components. In fact, there’s a collection of tooling to help with the design and management of reusable components. This suggests that the React community should provide significant existing explicit support (even components) for a Card interface. A Google search for “react card interface” supports that suggestion.

React Frameworks

Since React is a fairly low level Javascript UI library, there’s a lot of space for frameworks that provide pre-built components. Here’s a list of 20+ such React libraries/frameworks.

There’s Material-UI. Based on a design from another Internet behemoth (Google). Material-UI is described as a REACT UI framework. It’s open source. It supports a long list of components, including Cards. The Card component appears quite flexible. Beyond that, there are templates and example applications. There is a collection of premium themes and templates. Some people seem to like it. There are those that have problems with Google’s work on the design of the Material guidelines that Material-UI is based on.

React Toolbox is another implementation of Google’s Material design into React. It has support for CSS Modules, which may be useful for CASA. Need to explore if Material-UI also supports this, and if this will work in the Blackboard context.

If you don’t use Google’s Material. Then there is Ant Design and the React UI library based on it. It has a Card component and many of the same things as Material-UI. Or perhaps IBM’s Carbon. Not as complete, but supports React.

Or perhaps React Bootstrap. i.e. Bootstrap rebuilt using React, but still maintaining compatibility with the Bootstrap UI ecosystem (e.g. themes).

Content Interface

In a course context, the Card Interface is used to give an overview of learning modules. The Content Interface embodies design knowledge in Javascript which is then used to transform a HTML description of a learning module into a more interactive Web experience. As the (bad) title suggests this CASA initial focused on presenting content. Currently using the jQuery accordion to produce something like the following. The long term aim is to provide more support for interactive learning and teaching activities.