Reprise du message précédent :
Ghost et Discourse bienvenue dans le nouveau monde !
Si tu as besoin d'aide

+1.
 
BBS, j'avais fait le tour de tout ce que j'ai pu trouver et mon choix s'était arrêté sur DISCOURSE lorsque j'avais ce projet (depuis enterré).

Là je me rends compte que je suis bientôt quadragénaire BORDEL.

 
FluxBB, la dernière release à 18 mois, la communauté n'a pas l'air hyper active.
Wordpress a aussi un plugin bbpress pour monter un forum, c'est ce service qui pourrait m'intéresser.
phpBB semble être une valeur sûr.
 
Discourse, pas mal ouaih. et c'est responsive design, un bon point.

Discourse est la merde la plus insupportable que je connaisse, je supporte pas les forums discourse, c'est lourd à crever et les interactions sont immondes

NodeBB est pas trop mal (je l'utilise pour le forum de XO)

Ah !? Intéressant. Tu peux détailler ce que tu n'aimes pas ? Sur quels forums te bases-tu pour en arriver à cette conclusion ?

Hello,

J'ai une question React niveau ultra débutant .
Par curiosité j'ai commencé il y a genre 1h à regarder ReactJS. Je n'ai pas suivi de tutos, je suis parti d'un Hello World, à savoir le template par défaut de Microsoft quand on crée un projet MVC Core 2.0 avec react et redux.

Le machin comporte un formulaire avec un bouton qui vient incrémenter une variable.
Je me suis dit naïvement "tiens je vais rajouter un bouton pour décrémenter et un bouton pour la RAZ".

C'est là que tout dérape

Je vous partage les fichiers .tsx (en premier) et .ts (en second)

Mon problème est dans le .ts lignes 43 à 45 : vous n'aurez pas manqué l'horrible chose que je suis obligé de faire pour ramener à 0 ma variable.
       

C'est très moche mais c'est tout ce qui fonctionne.
   
Si à la place j'écris :

Ou

Ca s'exécute bien mais dans ce cas, dans ma phrase Current count: <strong>{ this.props.count }</strong> la valeur affichée ne change pas lors du clic sur Reset.
Mais il semble que le 0 soit bien pris en compte, car si je clique sur Increment ou Decrement, la valeur repart bien de 0.

Pourtant on devrait pouvoir affecter une constante à une variable liée à l'état donc je ne comprend pas pourquoi ce comportement bizarre. Encore une fois je n'ai jamais fait de React et j'ai un niveau misérable en JS pur, merci de votre indulgence .

PS : désolé c'est verbeux mais la partie significative tient en très peu de lignes .

Merci

Je connais pas redux (et c'est plus un problème redux que react) mais t'es généralement pas censé modifier l'état en place. Pourquoi tu renvoies pas juste {count:0}?

Mais je ne suis pas sensé faire un truc avec mon objet "state" (comme les autres méthodes) ?
Genre éventuellement :
   state.count = 0;
   return {count: 0}

Sinon il me semblait avoir aussi déjà testé  le return {count: 0} mais sans aucune différence, je reverrai.
Merci

Je connais pas redux mais je crois que :

State c'est ton état courant. Tu ne le modifie pas. Tu ne fais toujours qu'en créer un nouveau. La plupart du temps le nouveau que tu crées est fonction de l'état courant, mais pas toujours. Ton petit bout de code l'illustre très bien : tu incrementes et decrementes l'état courant, mais le reset s'en fiche complètement de l'état courant puisque tu le repasse à 0 quoi qu'il arrive

Bah je pense que non, les autres utilisent state parce qu'ils se basent dessus (pour incrementer ou décrementer un bout), là tu veux faire un reset donc tu dis juste quelle valeur tu veux.

D'ailleurs la doc de redux dit bien que

"state" étant un argument, t'es bien censé pas le toucher modifier.

et le seul endroit ou tu peux faire this.state = bidule c'est dans le constructeur de ton composant  
 
Sinon, tu dois utiliser setState()

Notes que là il est dans redux pas dans react, s'pas le même état.

a oui, bien vu

Vous feriez mieux de lui apprendre à apprendre

C'est parfaitement logique .
Je suppose que le return { count: 0 }; va en même temps affecter la valeur actuelle du "state.count" par un mécanisme planqué quelque part.
Faut que je lise un peu sur Redux pour savoir ce que c'est et où ça commence dans mon exemple .

J'ai ouvert ça pour tuer 1h de temps hier et regarder à quoi ça ressemble, d'où le côté bordélique de la démarche.
Je ne suis pas développeur front end JS machin (tout ce que je fais en JS c'est du jQuery), et je me commencerai à apprendre à apprendre seulement si ça s'impose .
Et c'est pas gagné pour en avoir envie, pour l'instant les quelques exemples que j'ai vu me font l'effet d'être des usines à gaz pour peu de chose à la fin, même si le côté SPA et cie est sympa.

edit : et mais en fait le même exemple sans Redux c'est vachement plus direct et simple . Plus d'usine à gaz.

dans Redux, le state c'est le single source of truth, et il est immutable, et dans les reducers tu n'as seulement le droit que de retourner un nouveau state dans ton reducer.

Les autres méthodes ne font rien sur le state regarde :  

 
dans ces cas tu ne fais que reprendre l'état actuel et l'incrémenter ou le décrémenter

Oui j'ai vu ça en postant, mais je préférais éviter d'écrire des tartines en posant plus de questions bêtes et juste attendre l'explication

Mais quel merdier    

Je ne sais pas si tu es familier ou non de ces trucs, mais c'est exactement ce que je me suis dit aussi.

La version avec juste React est déjà plus légère (là apparemment c'est Redux qui ajoute tout un bordel d'interfaces et d'actions avec une sorte de switch pour brancher tout ça ensemble), et la version avec Angular encore mieux selon moi (moins verbeux, moins de "wiring" en tout genre, meilleur découpage des fichiers avec les templates / l'initialisation / les méthodes chacun dans leur coin, etc).
N'étant pas un fan des JS monstrueux ça me parle plus quand ça va droit au but.
Même si j'imagine que cette structure ultra lourde a probablement aussi un intérêt pour certaines applis lourdes, sinon ça n'existerait pas...

Je croyais l'avoir déjà vu passer mais c'est une lecture nécessaire:  
 
https://medium.com/@dan_abramov/you [...] 46360cf367
You Might Not Need Redux

Perso j'aime bien la logique sous-tendante à Redux, c'est juste qu'en JS/TS ça ressemble à rien.

En Elm par contre…

Je préfère tellement mobx, même si c'est moins découplé

Mais carrément, pour moi c'est un énorme merdier.

Pour info, voici la version Angular de la même page (sans les actions, le reducer et cie, donc "moins découplé", mais avec quand même tout le nécessaire) :

La page :

Le fichier de script :

En comparaison, pas la peine de préciser à quel point c'est 100% lisible et maintenable même pour un neuneu du js.

Et à côté j'ai aussi modifié l'autre exemple Angular du template .Net Core MVC qui affiche la météo en faisant des appels serveurs dans la même appli SPA pour y ajouter une pagination et quelques méthodes.
Ben le truc est aussi court, lisible, et facile à comprendre et à enrichir que cet exemple, et le langage de templating aussi sympa.

Moralité : je n'en connaissais aucun, j'ai testé à l'arrache React, React + Redux, Angular, et j'aime considérablement plus Angular .
C'est subjectif (donc les fans de react pas la peine de me tomber sur le poil) et basé sur une expérience très rapide, mais le constat est indéniable.

Je sais bien qu'il y en a d'autres (Vue, Ember, Aurelia, Knockout... C'est la jungle ces machins, vivement que les technos prennent un peu de maturité) mais faut bien commencer quelque part .

fr(e)actal sinon

Jamais entendu parler, et google non plus

Si tout est dans le même composant ( ce qui est le cas pour angular, sauf erreur de ma part)

class CounterComponent extends React.Component{
    state = {
         counter:0
    }
    increment = ()=>{   
        this.setState({counter:this.state.counter+1})
   } 
    decrement = ()=>{   
        this.setState({counter:this.state.counter-1})
   } 
    reset = ()=>{
        this.setState({counter:0})
   } 
 
    render(){
      const {counter} = this.state
       return <div>
                     <h1>Counter</h1>
                     <p>This is a simple example of an Angular component.</p>
                     <p>Current count: <strong>{ counter }</strong></p>
                     <button onClick={this.increment}  >Increment</button>
                     <button onClick={this.decrement}>Increment</button>
                     <button onClick={this.reset}>Reset counter</button>
                 </div>
    }
}

Moi je trouve ça plutôt propre

Redux n'est pas forcement nécessaire

Clarification reset  = ()=>{ } force le fait que reset soit "bind" a this , et évite un peu de code

version en séparant le composant de présentation, et celui de contrôle (j'aime bien cette séparation)

class CounterPresentation extends React.PureComponent{
  render(){
  const {counter,increment,decrement,reset}  = this.props
     return <div>
                   <h1>Counter</h1>
                   <p>This is a simple example of an Angular component.</p>
                   <p>Current count: <strong>{ counter }</strong></p>
                   <button onClick={increment}  >Increment</button>
                   <button onClick={decrement}>Increment</button>
                   <button onClick={reset}>Reset counter</button>
               </div>
  }
}
 
 
class CounterController extends React.Component{
 state = {counter:0}
 increment = ()=>{   
      this.setState({counter:this.state.counter+1})
 } 
  decrement = ()=>{   
      this.setState({counter:this.state.counter-1})
 } 
  reset = ()=>{
      this.setState({counter:0})
 } 
  render(){
    const {counter} = this.state
     return <CounterPresentation 
        counter={this.state.counter}
       increment={this.increment}
       decrement={this.decrement}
       reset={this.reset}
      />
  }
}

Bah c'est mon coup de gueule de moment. J'ai vraiment l'impression qu'on a détourné React de son utilisation primaire et j'ai de gros doutes sur sa capacité à scaler sur un gros projet. L'approche 100% fonctionnelle qu'on en fait est en ligne avec l'approche réactive, mais la complexité explose quand on prend en compte les contraintes impératives d'une application web.
 

This.
 

This.

https://github.com/FormidableLabs/freactal

J'aurais plus à voir le problème inverse perso, c'est une approche sémantiquement simple mais très fonctionnelle et pure alors que le JS est un langage impératif et impur, donc t'as des "trous" entre l'approche et le language que tu dois combler à coup de mortier syntactique (appels de fonctions ou constructions complexes), et si le projet est simpliste (genre un compteur) bah tu te retrouves avec plus de mortier que de caillasse dans ton mur. Je m'attendrais à ce qu'avec la croissance du projet et la complexification de la logique la quantité relative de mortier diminue, et celle de caillasse augmente.
 
Et TS me semble pas aider non plus ici, il augmente notablement les frais (le reducer c'est 50% de bordel TypeScript) sans améliorer la paie.
 
Parce-que exactement la même logique/sémantique dans un language plus adapté (Elm) ça donne:

import Html exposing (..)
import Html.Events exposing (onClick)

main : Program Never Model Msg
main =
    beginnerProgram { model = model, view = view, update = update }

-- normalement j'utiliserais Model = Int mais je colle à l'originel
type alias Model =  
    { count : Int }
model : Model
model =  
    { count = 0 }

type Msg
    = Increment
    | Decrement
    | Reset
update : Msg -> Model -> Model
update msg model =
    case msg of
        Increment ->
            { model | count = model.count + 1 }
        Decrement ->  
            { model | count = model.count - 1 }
        Reset ->  
            { model | count = 0 }

view : Model -> Html Msg
view model =
    div []
        [ h1 [] [ text "Counter" ]
        , p [] [ text "This is a simple example of an Elm view" ]
        , p [] [ text "Current count: "
               , strong [] [ text ( toString model.count ) ]
               ]
        , button [ onClick Increment ] [ text "Increment" ]
        , button [ onClick Decrement ] [ text "Decrement" ]
        , button [ onClick Reset ] [ text "Reset count" ]
        ]

 
Alors oui il faut connaître la syntaxe et t'as pas du jsx-qui-ressemble-à-du-HTML, mais pour moi la clarté et le ratio logique/frais est quand même pas dégueu. Et encore une fois c'est pas une question de

c'est dedans, le flux unidirectionnel avec une logique applicative atomique est là, c'est juste que le langage est mieux adapté à cette utilisation. Et les types sont statiques et costauds et explicites (mon dernier bricolage en elm, tous les bugs que j'ai eu qui ont passé la compilation était dans les bricolage de chaînes de caractères).
 
(nota: j'ai même pas testé le code localement avant de le poster ici, mais je l'ai collé dans http://elm-lang.org/try histoire de et il fonctionne du premier coup )

C'est pas délirant comme analyse, et pourtant quand on conserve une approche impérative en gardant de l'isolation, ça reste très lisible et beaucoup moins bloaté.

import Html exposing (..)
import Html.Events exposing (onClick)

main : Program Never Model Msg
main =
    beginnerProgram { model = model, view = view, update = update }

-- normalement j'utiliserais Model = Int mais je colle à l'originel
type alias Model =  
    { count : Int }
model : Model
model =  
    { count = 0 }

type Msg
    = Increment
    | Decrement
    | Reset
update : Msg -> Model -> Model
update msg model =
    case msg of
        Increment ->
            { model | count = model.count + 1 }
        Decrement ->  
            { model | count = model.count - 1 }
        Reset ->  
            { model | count = 0 }

view : Model -> Html Msg
view model =
    div []
        [ h1 [] [ text "Counter" ]
        , p [] [ text "This is a simple example of an Elm view" ]
        , p [] [ text "Current count: "
               , strong [] [ text ( toString model.count ) ]
               ]
        , button [ onClick Increment ] [ text "Increment" ]
        , button [ onClick Decrement ] [ text "Decrement" ]
        , button [ onClick Reset ] [ text "Reset count" ]
        ]

Mais oui putain    
 

C'est pas en opposition à ce que je dis, quand tu restes dans les forces et la logique du langage t'as moins de bricolage à ajouter pour combler les trous, donc t'as moins de bruit et plus de signal. Et je pense que plus le projet est petit (moins il a de signal) et plus c'est sensible, parce que dans mon expérience les frais croient généralement sous-linéairement (même si selon le système tu peux avoir des "murs" avec des croissances brutales par endroit).

Notes que ça veut pas dire que tu finis nécessairement par t'y retrouver (let me tell you about struts), et que je suis pas vraiment emballé ou convaincu par redux (et je trouve bizarre de le mettre comme template pour débutant). Mais bon. Après

je sais pas si MS a pas des meilleurs templates pour débutants ou application basiques. Et autogénérer des platrées de merde me semble dans la lignée de mes souvenirs de leurs templates Win32

Je pense aussi que Redux est le mauvais élève de la bande.

J'ai un backoffice, où je dois récupérer des données.
Il faut au préalable se connecter avant, via un simple formulaire (j'ai les accès).
Seulement, je dois accéder à une URL précise pour avoir les détails de chaque entité que je veux (genre http://api.domaine.fr/api/admin/places/2).
J'ai environ 3300 entité, donc pas la peine de le faire à la main...

Le formulaire de login a cette gueule :

(Grosso modo c'est du généré)

J'ai tenté de me connecter en php via un script local avec curl, mais ça m'envoie bouler

Je voulais juste me connecter via php et via une petite boucle, récupérer en file_get_content toutes les urls souhaitées.
Des tips ?
Thx

Ben ton script n'est pas connecté
Donc faut te connecter d'abord et pour ça faut savoir comment se fait la connexion

Ah non c'était pas les templates, c'était le Win32 qui était naturellement comme ça
 
Pour React/Redux j'ai pas d'avis sur "Est ce que ça aurait pu être plus propre avec les même outils" vu que j'ai découvert juste par ça, mais effectivement c'est dégueu tel que dans cet exemple

Justement, j'ai tenté de me connecter en curl, mais ça veut rien savoir.