web-dev-qa-db-fra.com

Créer une application JS distincte pour un poste individuel?

Automattic construit un thème basé sur React.js appelé Picard . Tout le code JS est dans picard.js, auquel vous pouvez voir une référence ci-dessous. Bien que WordPress n’ait pas de "routeur" en soi ( comme expliqué ici ), React.js le fait et il est utilisé dans cette application pour changer l'URL lorsqu'un message est affiché.

Ma question est , si je voulais créer une application JS pour afficher les publications (par exemple dans un fichier appelé posts.js), comment puis-je utiliser une autre application JS (par exemple dans un fichier appelé post.js) pour afficher une publication individuelle?

En d'autres termes, si je ne souhaite pas utiliser de routeur côté client, mais simplement créer une petite application JS (et la charger paresseuse) pour une publication individuelle, puis si un utilisateur clique en arrière pour afficher les listes de publications, avoir posts.js chargé.

function picard_scripts() {
    wp_enqueue_style( 'picard-style', get_stylesheet_uri(), '20150405' );
    wp_register_script( 'picard-script', get_template_directory_uri() . 
        '/picard.js', array(), '20150506', true );
    wp_enqueue_script( 'picard-script' );
    wp_enqueue_style( 'genericons', get_template_directory_uri() . 
        '/genericons/genericons.css', array(), '3.4' );
}
add_action( 'wp_enqueue_scripts', 'picard_scripts' );

Au cas où vous vous le demanderiez, je ne souhaite pas utiliser de routeur côté client car je les trouve bogués, mais je souhaite créer des interfaces utilisateur en JavaScript. Je préférerais donc pouvoir compter uniquement sur WordPress pour gérer l'URL/le routage. (même si WordPress n’a pas de routeur).

postsjavascripturlsrouting
2
Leahcim

Je vais essayer de préparer une réponse en fonction de ma compréhension des informations fournies.

Je vais exposer quelques hypothèses avant de commencer à comprendre la logique:

1) Comme Picard, vous contournerez la hiérarchie standard de modèles WP au profit d'un chut d'index.php.

2) Les points de terminaison seront fournis par le plug-in API WP REST.

3) Afin de garder le thème aussi simple que possible, nous placerons la logique de routage dans functions.php.

À partir de là, vous devez décider si le site sera créé sous la forme d’une application asynchrone à page unique ou d’un site Web de style demande/réponse standard.

L'application à page unique s'appuiera davantage sur le routage frontal. Vous pouvez également avoir les fichiers posts.js et post.js préchargés en fonction de votre structure/framework JS. Vos URL contiendront des hachages et votre JS mappera les itinéraires aux points de terminaison de l'API.

// basic example - your route patterns may vary
http://domain.com/#posts
http://domain.com/#post/my-post-slug

Le site Web de style standard permettra à PHP de gérer le routage. Vos URL suivront la structure standard WP et functions.php mettra en file d'attente vos bibliothèques JS en fonction de la requête:

// very basic routing logic - add any conditions as needed
function enqueue_template_scripts() {
    // load posts.js for blog page
    if(is_home()) {
        wp_enqueue_script('post-list', 'posts.js');
    }
    // load post.js for single requests
    if(is_single()) {
        wp_enqueue_script('post-single', 'post.js');
    }
}
add_action('wp_enqueue_scripts', 'enqueue_template_scripts');

REMARQUE: D'autres crochets d'action peuvent fonctionner mieux pour vous en fonction de ce que vous choisissez de faire dans votre logique de routage. J'ai utilisé 'wp_enqueue_scripts' dans cet exemple pour démontrer l'inclusion de script.

1
dswebsme