* Remove hardcoded instances of education field * WIP Access display_email_on_profile via User Settings * Remove unused profile column * WIP Fix reference to bg_color_hex and text_color_hex * WIP fix issues revealed by systems specs * WIP fix issues revealed by services specs * WIP Fix failing tests * WIP Fix spec failures * wip * Move two attributes from controller to decorator * Update comment * Match user settings changes * More consistently use user.tag_line Even before the profile changes we sometimes used the user.summary attribute directly but used the user.tag_line method in other places. * Remove delegation, rename inline concern * Drop profile columns from users table * Remove duplicated work display from header * Update work profile field handling * Update DUS + spec * Delegate more carefully * Update delegation guard * Adapt for removed delegation * Undo accidental schema changes * Fix seeds * Remove accidentaly change * Fix User#processed_website_url * Update guard clause * Update profile card content * Add Organization#profile * Be more conservative with profile fields * Spec fixes round 1 * Fix typo * Update spec * Limit number of header fields and update card content * Decorate correct model * Update factory * Update schema.rb * Fix validation * How bad could this possibly be? * Pretty bad, nevermind * Remove obsolete code * Reset profile fields during test runs * Move profile fields back to before(:suite) * Spec fixes * Remove accidentally re-added files * More spec fixes * Specs * Change User#tag_keywords_for_search * More spec fixes * Add comment * Undo accidental schema changes * Attempt spec fix * Remove fix attempt * Fix e2e test * Update spec * Remove guard clause * Remove hardcoded instances of education field * WIP Access display_email_on_profile via User Settings * Remove unused profile column * WIP fix issues revealed by systems specs * WIP fix issues revealed by services specs * WIP Fix failing tests * WIP Fix spec failures * wip * Move two attributes from controller to decorator * Update comment * More consistently use user.tag_line Even before the profile changes we sometimes used the user.summary attribute directly but used the user.tag_line method in other places. * Remove education * Add comment * WIP * Clean up mostly_work_with * WIP * Update work profile field handling * More work-related changes * Remove settings_only from display_area enum * Remove quickfix from _metadata partial * Remove special attributes * Remove leftover spec * Retrieve location from profile, not user * Profile.special_attributes no longer exists * Update specs * More spec fixes * Update UsersController * Update UsersController and spec * Fix e2e seeds * Minor cleanup * More e2e seed fixes * Fix profile field CSV * Fix e2e seeds * Move one more attribute in e2e seeds * Remove duplicate line * Clear inputs before typing in them * Fix formatting issues * Profiles::Update -> Users::Update * Remove RegistrationsController#resolve_profile_field_issues * Fix schema.rb * More cleanup * Fix specs * Fix remaining spec Co-authored-by: Jacob Herrington <jacobherringtondeveloper@gmail.com>
2.6 KiB
| title |
|---|
| Preact |
Preact
Preact is an alternative to React with the same modern API.
Preact components are packaged using Webpacker and the
Preact code is located in app/javascript.
Preact components get loaded via webpacker's helper function
javascript_packs_with_chunks_tag.
PropTypes
Preact supports PropTypes. When creating Preact components, please ensure that you have defined your PropTypes.
Common PropTypes
Using PropTypes can be repetitive. Some duplication is normal, like when a
PropType is a string or a number. But for commonly-used PropTypes, like the user
entity, you can use the provided common PropTypes, located in the
/app/javascript/common-prop-types, as shown below.
import PropTypes from 'prop-types';
export const userPropTypes = PropTypes.shape({
id: PropTypes.string.isRequired,
name: PropTypes.string.isRequired,
profile_image_url: PropTypes.string.isRequired,
summary: PropTypes.string.isRequired,
});
Using Common PropTypes
Common PropTypes are imported just like any other
JavaScript Module.
For example, here are two scenarios where a component needs to use the
tagPropTypes.
In the example below, our component SomeComponentUsingTags has a tags prop,
which is an array of the tag entity. PropTypes have a built-in method called
arrayOf that allows you to define a prop as an array of something. In our
case, this is the tag entity, so we can use the tagPropTypes PropType.
import { h } from 'preact';
import PropTypes from 'prop-types';
import { tagPropTypes } from '../../../components/common-prop-types';
const SomeComponentUsingTags = ({ tags = [] }) => (
<ul>
{tags.map((tag) => (
<li key={tag.id}>{tag.name}</li>
))}
</ul>
);
SomeComponentUsingTags.displayName = 'SomeComponentUsingTags';
SomeComponentUsingTags.propTypes = {
tags: PropTypes.arrayOf(tagPropTypes).isRequired,
};
In the following example, the SomeComponentUsingOneTag component has a tag
prop representing a single tag. In this case, we can just the tagPropTypes on
their own to represent the shape of the tag prop.
import { h } from 'preact';
import { tagPropTypes } from '../../../components/common-prop-types';
const SomeComponentUsingOneTag = ({ tag }) => <li key={tag.id}>{tag.name}</li>;
SomeComponentUsingOneTag.displayName = 'SomeComponentUsingTags';
SomeComponentUsingOneTag.propTypes = {
tag: tagPropTypes.isRequired,
};